From michael.anderson at elego.de Wed Jul 1 11:03:19 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 01 Jul 2009 11:03:19 +0200 Subject: [M3devel] elego Servermaintenance 3.07.09 Message-ID: <20090701110319.l4ksn5e680ggg4kk@mail.elego.de> Liebe Kollegen, Liebe Elego-Kunden, In der Nacht von Freitag, dem 3.07 auf Samstag, den 4.07 werden wir um 22.00 CEST Uhr planmaessige Wartungsarbeiten an unseren Servern durchfuehren. Es kann zur kurzeitigen Unterbrechung mancher Dienste kommen. Voraussichtliche Dauer der Wartung: 120 Min. Wir bitten um Verst?ndnis. - die elego Admins On Friday, July 3 at 10 PM CEST, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 1 13:57:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Jul 2009 13:57:15 +0200 Subject: [M3devel] release build broken In-Reply-To: References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> Message-ID: <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> Quoting Jay : > > Ah, only the release build but not the latest, makes sense. > These weren't in m3core in older version. > Will fix. > After this release I can put it back. Jay, all the release builds are still broken in Tinderbox. Can you fix it your revert the offending commit? You also didn't answer if you're going to fix the path canonicalization function in quake. Can you do something there? Thanks, Olaf > > - Jay > > > > ---------------------------------------- >> Date: Tue, 30 Jun 2009 09:28:26 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release build broken >> >> The last commit to pkginfo.txt broke the Tinderbox release build: >> >> End of Log File >> "../src/Main.m3", line 4: unable to find interface (WinNT) >> "../src/Main.m3", line 5: unable to find interface (WinDef) >> compilation failed => not building program "mklib" >> Fatal Error: package build failed >> *** execution of cm3 -build >> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >> -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS >> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >> -DCM3_LAST_CHANGED=?2009-05-16? failed *** >> >> >> Please fix. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 1 17:45:05 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 15:45:05 +0000 Subject: [M3devel] release build broken In-Reply-To: <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> Message-ID: Release build should be ok now, for the next build. I'm not sure about the path stuff. What I was doing uses working code. - Jay ---------------------------------------- > Date: Wed, 1 Jul 2009 13:57:15 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release build broken > > Quoting Jay : > >> >> Ah, only the release build but not the latest, makes sense. >> These weren't in m3core in older version. >> Will fix. >> After this release I can put it back. > > Jay, > > all the release builds are still broken in Tinderbox. Can you fix it > your revert the offending commit? > > You also didn't answer if you're going to fix the path canonicalization > function in quake. Can you do something there? > > Thanks, > > Olaf > >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 30 Jun 2009 09:28:26 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] release build broken >>> >>> The last commit to pkginfo.txt broke the Tinderbox release build: >>> >>> End of Log File >>> "../src/Main.m3", line 4: unable to find interface (WinNT) >>> "../src/Main.m3", line 5: unable to find interface (WinDef) >>> compilation failed => not building program "mklib" >>> Fatal Error: package build failed >>> *** execution of cm3 -build >>> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >>> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >>> -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS >>> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >>> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >>> -DCM3_LAST_CHANGED=?2009-05-16? failed *** >>> >>> >>> Please fix. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 1 18:09:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 16:09:53 +0000 Subject: [M3devel] small builder bug when delete/rename files Message-ID: I believe there is a small builder bug for incremental builds when you move files: == package /home/jay/dev2/cm3/m3-sys/cm3 == +++ /tmp/tmpLXKqFE/compiler_with_previous/bin/cm3 -build -DROOT=/home/jay/dev2 /cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=20 09-05-16 @M3novm +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides Fatal Error: duplicate link info: M3Path.i3 *** execution of [, From jay.krell at cornell.edu Wed Jul 1 18:14:46 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 16:14:46 +0000 Subject: [M3devel] ChangeLog missing entries Message-ID: Many entries aren't interesting anyway, but the ChangeLog does miss stuff, at lease this one: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/intl/Attic/Makefile.in remove intl, libgomp, libssp, libmudflap that we don't build, use, or change http://modula3.elegosoft.com/cm3/ChangeLog-2009 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 1 18:54:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Jul 2009 18:54:03 +0200 Subject: [M3devel] ChangeLog missing entries In-Reply-To: References: Message-ID: <20090701185403.lgnqptijkg8g0w4w@mail.elegosoft.com> Quoting Jay : > Many entries aren't interesting anyway, but the ChangeLog does miss > stuff, at lease this one: > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/intl/Attic/Makefile.in > > remove intl, libgomp, libssp, libmudflap that we don't build, use, or > change > > > http://modula3.elegosoft.com/cm3/ChangeLog-2009 It's converted by a standard Perl script from the repository, IIRC. It's run by m3's crontab every on birch. Anybody there who'd like to have a look? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Jul 2 08:54:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Jul 2009 23:54:42 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Hi Modula-3ers (Tony?), I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot archive is broken on the web site... I remember there is some more or less hidden area where there are more archives, but I don't remember where? Mika From jay.krell at cornell.edu Thu Jul 2 09:08:58 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 07:08:58 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020654.n626sg3G082786@camembert.async.caltech.edu> References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: modula3.elegosoft.com/cm3/uploaded-archives But there aren't any I386_DARWIN. My I386_DARWIN seems to have a problem with its power supply, that's partly why nothing in releng. Can I suggest you try cross bootstrap? You know, so I can induct other people into my fun group? Here is how. Have some working machine already. Pretty much any platform. cd m3-sys/m3cc cm3 -DM3CC_TARGET=I386_DARWIN # That takes a little while. cd scripts/python cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. That config file delegates to the config files in the CVS tree. ./boot1.py I386_DARWIN This will produce something like ./cm3-boot-I386_DARWIN-1.tar.gz scp that file to your I386_DARWIN machine, then the rest is on the I386_DARWIN machine, extract it, cd into it, run make. That should give you cm3. Run it, make sure it runs ok, it should error about unable to find cm3.cfg. cvs checkout the whole tree. mkdir -p /usr/local/cm3/bin/config cp cm3 /usr/local/cm3/bin cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. You know have a working native bootstrap -- just cm3, cm3.cfg, the source tree. Complete the system with: ./do-cm3-std.py buildship - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Wed, 1 Jul 2009 23:54:42 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting I386_DARWIN? > > Hi Modula-3ers (Tony?), > > I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot > archive is broken on the web site... I remember there is some more or > less hidden area where there are more archives, but I don't remember > where? > > Mika From jay.krell at cornell.edu Thu Jul 2 09:41:56 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 07:41:56 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: Sorry, that was wrong: cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config should be: cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin I moved all the other files to config, but not cm3.cfg itself. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 07:08:58 +0000 > CC: mika at camembert.async.caltech.edu > Subject: Re: [M3devel] help booting I386_DARWIN? > > > modula3.elegosoft.com/cm3/uploaded-archives > > > But there aren't any I386_DARWIN. > My I386_DARWIN seems to have a problem with its power supply, that's partly why nothing in releng. > > > Can I suggest you try cross bootstrap? > You know, so I can induct other people into my fun group? > > > Here is how. > Have some working machine already. > Pretty much any platform. > > > cd m3-sys/m3cc > cm3 -DM3CC_TARGET=I386_DARWIN > # That takes a little while. > > > cd scripts/python > cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. > That config file delegates to the config files in the CVS tree. > > ./boot1.py I386_DARWIN > This will produce something like > ./cm3-boot-I386_DARWIN-1.tar.gz > > > scp that file to your I386_DARWIN machine, > then the rest is on the I386_DARWIN machine, > extract it, cd into it, run make. > That should give you cm3. > Run it, make sure it runs ok, it should error about unable to find cm3.cfg. > > > cvs checkout the whole tree. > mkdir -p /usr/local/cm3/bin/config > cp cm3 /usr/local/cm3/bin > cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. > > You know have a working native bootstrap -- just cm3, cm3.cfg, the source tree. > Complete the system with: > > > ./do-cm3-std.py buildship > > > > - Jay > > ---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Wed, 1 Jul 2009 23:54:42 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] help booting I386_DARWIN? >> >> Hi Modula-3ers (Tony?), >> >> I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot >> archive is broken on the web site... I remember there is some more or >> less hidden area where there are more archives, but I don't remember >> where? >> >> Mika From mika at async.caltech.edu Thu Jul 2 10:06:51 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 02 Jul 2009 01:06:51 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020806.n6286pFG085097@camembert.async.caltech.edu> Jay that's pretty nifty. The "cross" part of the build went fine (I figured out your config thing too), but it dies on the target: as PolyBasis.ms -o PolyBasis.ms.o as Main.is -o Main.is.o as WeakRef.ms -o WeakRef.ms.o as Word.ms -o Word.ms.o as Long.ms -o Long.ms.o gcc -g -fPIC -c hand.c -o hand.c.o gcc -g -fPIC -c dtoa.c -o dtoa.c.o gcc -g -fPIC -c libgcc.c -o libgcc.c.o gcc -g -fPIC -c RTLinkerC.c -o RTLinkerC.c.o gcc -g -fPIC -c RTOSmmap.c -o RTOSmmap.c.o gcc -g -fPIC -c RTSignalC.c -o RTSignalC.c.o RTSignalC.c: In function 'GetPC': RTSignalC.c:91: error: 'struct mcontext' has no member named 'sc' make: *** [RTSignalC.c.o] Error 1 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% uname -a Darwin unknown-00-17-f2-4c-66-5c.home 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% Am I perhaps using a hopeless version of OS X? Mika From jay.krell at cornell.edu Thu Jul 2 10:46:26 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 08:46:26 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020806.n6286pFG085097@camembert.async.caltech.edu> References: <200907020806.n6286pFG085097@camembert.async.caltech.edu> Message-ID: Just change the function GetPC to return 0 and move on, for now. We'll fix it correctly "later". I assume you are running 10.5? It worked for me on 10.4. There might be an #ifdef we can use to make it work on both. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jayk123 at hotmail.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 01:06:51 -0700 > From: mika at async.caltech.edu > > Jay that's pretty nifty. The "cross" part of the build went fine (I > figured out your config thing too), but it dies on the target: > > as PolyBasis.ms -o PolyBasis.ms.o > as Main.is -o Main.is.o > as WeakRef.ms -o WeakRef.ms.o > as Word.ms -o Word.ms.o > as Long.ms -o Long.ms.o > gcc -g -fPIC -c hand.c -o hand.c.o > gcc -g -fPIC -c dtoa.c -o dtoa.c.o > gcc -g -fPIC -c libgcc.c -o libgcc.c.o > gcc -g -fPIC -c RTLinkerC.c -o RTLinkerC.c.o > gcc -g -fPIC -c RTOSmmap.c -o RTOSmmap.c.o > gcc -g -fPIC -c RTSignalC.c -o RTSignalC.c.o > RTSignalC.c: In function 'GetPC': > RTSignalC.c:91: error: 'struct mcontext' has no member named 'sc' > make: *** [RTSignalC.c.o] Error 1 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% uname -a > Darwin unknown-00-17-f2-4c-66-5c.home 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > Am I perhaps using a hopeless version of OS X? > > Mika From mika at async.caltech.edu Thu Jul 2 10:55:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 02 Jul 2009 01:55:58 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020855.n628twBs086659@camembert.async.caltech.edu> Jay, all right, GetPC returns 0, and moving on.... [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make Makefile:3312: warning: overriding commands for target `UnixLink.c.o' Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' as M3Buf.ms -o M3Buf.ms.o M3Buf.ms:1610:operands given don't match any known 386 instruction M3Buf.ms:1618:operands given don't match any known 386 instruction make: *** [M3Buf.ms.o] Error 1 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms rep movsl movl %edx, -2184(%ebp) leal -2048(%ebp), %eax movl %eax, -2188(%ebp) movl $509, -2192(%ebp) movl -2184(%ebp), %edi movl -2188(%ebp), %esi movl -2192(%ebp), %ecx rep movsl [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% No this is what I have: [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S2167 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% odd that it would work for you... hmm I wonder, maybe the Xcode needs updating? A little tricky in that case since I don't have console access and am not really a Mac guru. Mika From jay.krell at cornell.edu Thu Jul 2 10:59:02 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 08:59:02 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: Right. Look at I386_DARWIN. It probes for this. You have two choices. - difficult -- put a newline after each lock Their assembler does understand that I recall. - get a newer assembler; that's what I did I386_DARWIN will tell you what version I used, I don't know if older works. or maybe we could/should change cm3cg here. Heck, maybe there's a change in Apple's gcc to merge in. Or maybe, heck, just remove all occurences of lock. You only have one processor, right? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Thu, 2 Jul 2009 01:55:58 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting I386_DARWIN? > > Jay, all right, GetPC returns 0, and moving on.... > > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make > Makefile:3312: warning: overriding commands for target `UnixLink.c.o' > Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' > as M3Buf.ms -o M3Buf.ms.o > M3Buf.ms:1610:operands given don't match any known 386 instruction > M3Buf.ms:1618:operands given don't match any known 386 instruction > make: *** [M3Buf.ms.o] Error 1 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms > rep movsl > movl %edx, -2184(%ebp) > leal -2048(%ebp), %eax > movl %eax, -2188(%ebp) > movl $509, -2192(%ebp) > movl -2184(%ebp), %edi > movl -2188(%ebp), %esi > movl -2192(%ebp), %ecx > rep movsl > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > No this is what I have: > > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers > ProductName: Mac OS X > ProductVersion: 10.4.11 > BuildVersion: 8S2167 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin8 > Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 > Thread model: posix > gcc version 4.0.1 (Apple Computer, Inc. build 5250) > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > odd that it would work for you... hmm I wonder, maybe the Xcode needs > updating? > > A little tricky in that case since I don't have console access and > am not really a Mac guru. > > Mika From jay.krell at cornell.edu Thu Jul 2 11:00:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 09:00:22 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: er, I guess it is rep, not lock, and removing it will break it. Update your assembler or insert newlines.. Sorry. Probably running on 10.5 fixes it too... I tried configuring for older processors, 586, 486, 386 I /think/ none of that worked. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 08:59:02 +0000 > > > Right. Look at I386_DARWIN. > It probes for this. > You have two choices. > - difficult -- put a newline after each lock > Their assembler does understand that I recall. > > > - get a newer assembler; that's what I did > I386_DARWIN will tell you what version I used, I don't know if older works. > > > or maybe we could/should change cm3cg here. > Heck, maybe there's a change in Apple's gcc to merge in. > > > Or maybe, heck, just remove all occurences of lock. > You only have one processor, right? > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Thu, 2 Jul 2009 01:55:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] help booting I386_DARWIN? >> >> Jay, all right, GetPC returns 0, and moving on.... >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >> Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' >> as M3Buf.ms -o M3Buf.ms.o >> M3Buf.ms:1610:operands given don't match any known 386 instruction >> M3Buf.ms:1618:operands given don't match any known 386 instruction >> make: *** [M3Buf.ms.o] Error 1 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms >> rep movsl >> movl %edx, -2184(%ebp) >> leal -2048(%ebp), %eax >> movl %eax, -2188(%ebp) >> movl $509, -2192(%ebp) >> movl -2184(%ebp), %edi >> movl -2188(%ebp), %esi >> movl -2192(%ebp), %ecx >> rep movsl >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> No this is what I have: >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4.11 >> BuildVersion: 8S2167 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >> Using built-in specs. >> Target: i686-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 >> Thread model: posix >> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> odd that it would work for you... hmm I wonder, maybe the Xcode needs >> updating? >> >> A little tricky in that case since I don't have console access and >> am not really a Mac guru. >> >> Mika From jay.krell at cornell.edu Thu Jul 2 11:02:33 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 09:02:33 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: Btw, You don't need "console" access, like to a gui or "xcode". I, and I believe Olaf, used the stripped down "Darwin" that Apple released before it was selling x86 hardware. They don't have current 10.5 builds of that available but they do have 10.4. It works on some "normal" (non-Apple) hardware like some Dell laptops. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 09:00:22 +0000 > > > er, I guess it is rep, not lock, and removing it will break it. Update your assembler or insert newlines.. > Sorry. Probably running on 10.5 fixes it too... > I tried configuring for older processors, 586, 486, 386 I /think/ none of that worked. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] help booting I386_DARWIN? >> Date: Thu, 2 Jul 2009 08:59:02 +0000 >> >> >> Right. Look at I386_DARWIN. >> It probes for this. >> You have two choices. >> - difficult -- put a newline after each lock >> Their assembler does understand that I recall. >> >> >> - get a newer assembler; that's what I did >> I386_DARWIN will tell you what version I used, I don't know if older works. >> >> >> or maybe we could/should change cm3cg here. >> Heck, maybe there's a change in Apple's gcc to merge in. >> >> >> Or maybe, heck, just remove all occurences of lock. >> You only have one processor, right? >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> To: jay.krell at cornell.edu >>> Date: Thu, 2 Jul 2009 01:55:58 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] help booting I386_DARWIN? >>> >>> Jay, all right, GetPC returns 0, and moving on.... >>> >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >>> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >>> Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' >>> as M3Buf.ms -o M3Buf.ms.o >>> M3Buf.ms:1610:operands given don't match any known 386 instruction >>> M3Buf.ms:1618:operands given don't match any known 386 instruction >>> make: *** [M3Buf.ms.o] Error 1 >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms >>> rep movsl >>> movl %edx, -2184(%ebp) >>> leal -2048(%ebp), %eax >>> movl %eax, -2188(%ebp) >>> movl $509, -2192(%ebp) >>> movl -2184(%ebp), %edi >>> movl -2188(%ebp), %esi >>> movl -2192(%ebp), %ecx >>> rep movsl >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >>> >>> No this is what I have: >>> >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >>> ProductName: Mac OS X >>> ProductVersion: 10.4.11 >>> BuildVersion: 8S2167 >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >>> Using built-in specs. >>> Target: i686-apple-darwin8 >>> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 >>> Thread model: posix >>> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >>> >>> odd that it would work for you... hmm I wonder, maybe the Xcode needs >>> updating? >>> >>> A little tricky in that case since I don't have console access and >>> am not really a Mac guru. >>> >>> Mika From lists at darko.org Thu Jul 2 12:16:29 2009 From: lists at darko.org (Darko Volaric) Date: Thu, 2 Jul 2009 12:16:29 +0200 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020654.n626sg3G082786@camembert.async.caltech.edu> References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: <107CE119-1777-4132-A24E-3C6075C625FD@darko.org> It's in Tony's private stash: ftp://ftp.cs.purdue.edu/pub/hosking/m3/ On 02/07/2009, at 8:54 AM, Mika Nystrom wrote: > Hi Modula-3ers (Tony?), > > I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot > archive is broken on the web site... I remember there is some more or > less hidden area where there are more archives, but I don't remember > where? > > Mika From wagner at elegosoft.com Thu Jul 2 12:35:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Jul 2009 12:35:33 +0200 Subject: [M3devel] stepping on your toes In-Reply-To: References: <20090629093610.blv4zraf4ocowk8w@mail.elegosoft.com> <35F93BA7-A05C-4633-89F0-211C5C0256EA@hotmail.com> <20090629110826.mkugfxs884c0owcc@mail.elegosoft.com> <20090701184824.6oeqk8cdbggw8owc@mail.elegosoft.com> <20090702082756.e5lkauyzfo44000k@mail.elegosoft.com> Message-ID: <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> Quoting Jay : > Olaf, the ws packages contain source and unshipped outputs, right? > What do you think is the point of these archives vs. binary-only and > source-only archives? I have ideas but I don't want to lead you. The idea was to reduce the number of packages, as M3 does not really support the separation of source and derived files for binary packages. So why not just enrich the source with just the products needed for shipping? This is sort of the smallest supported _M3_-binary package. Both system-dependent source and binary packages can be based on the same collection of ws packages. Traditionally CM3 offered only sources packages except for the minimal installation archive. There were lots of problems with o people understanding how to compile the source and o actual compilation errors due to miscellaneous causes People wanted something that is easy to install (without using lots of complex scripts). So I extended the standard cm3 builder so it can be used for such an installation. These are exactly the ws archives. M3 source and derived files which are needed for shipping an M3 package, but not more. I found that rather nice. >> core vs. min vs. boot > > Yeah I was equating min with boot. > Still, as to what is "minimal" vs. "useful", not clear. For example, > "minimal" can be reduced by not allowing for static linking. The > .sa files add a lot of size. But that is slightly less useful, so > someone who wants to make standalone programs. > And min still varies in definition depending on one's prediction of > the future. > > Even then there are multiple definitions here: > boot for the current matching release > or boot for the next release? > > If it is for the matching release, no problem predicting the future, > it is just the assembly code for cm3, and no provision for creating > a package store with any contents, until user also gets source and > builds it. I have in mind the old 3.6 release form, though we can't > quite emulate it, now that the builder is in M3 and not C. > > I'd like to look into this cross building of boot/assembly releases, > though first some other things.. The whole cross-compilation topic is not really relevant for a release IMO. There are very few people who actually want to do such things ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Jul 2 15:42:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 09:42:31 -0400 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: <073CA2E9-4E98-449E-B725-E478A0F8D20D@cs.purdue.edu> Best to upgrade xcode. On 2 Jul 2009, at 04:59, Jay wrote: > > Right. Look at I386_DARWIN. > It probes for this. > You have two choices. > - difficult -- put a newline after each lock > Their assembler does understand that I recall. > > > - get a newer assembler; that's what I did > I386_DARWIN will tell you what version I used, I don't know if > older works. > > > or maybe we could/should change cm3cg here. > Heck, maybe there's a change in Apple's gcc to merge in. > > > Or maybe, heck, just remove all occurences of lock. > You only have one processor, right? > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Thu, 2 Jul 2009 01:55:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] help booting I386_DARWIN? >> >> Jay, all right, GetPC returns 0, and moving on.... >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >> Makefile:687: warning: ignoring old commands for target >> `UnixLink.c.o' >> as M3Buf.ms -o M3Buf.ms.o >> M3Buf.ms:1610:operands given don't match any known 386 instruction >> M3Buf.ms:1618:operands given don't match any known 386 instruction >> make: *** [M3Buf.ms.o] Error 1 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n >> 1610,1618p M3Buf.ms >> rep movsl >> movl %edx, -2184(%ebp) >> leal -2048(%ebp), %eax >> movl %eax, -2188(%ebp) >> movl $509, -2192(%ebp) >> movl -2184(%ebp), %edi >> movl -2188(%ebp), %esi >> movl -2192(%ebp), %ecx >> rep movsl >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> No this is what I have: >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4.11 >> BuildVersion: 8S2167 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >> Using built-in specs. >> Target: i686-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure >> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man >> --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/ >> ^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- >> build=powerpc-apple-darwin8 --with-arch=pentium-m --with- >> tune=prescott --program-prefix= --host=i686-apple-darwin8 -- >> target=i686-apple-darwin8 >> Thread model: posix >> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> odd that it would work for you... hmm I wonder, maybe the Xcode needs >> updating? >> >> A little tricky in that case since I don't have console access and >> am not really a Mac guru. >> >> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 2 17:08:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 2 Jul 2009 11:08:17 -0400 Subject: [M3devel] stepping on your toes In-Reply-To: <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> References: <20090629093610.blv4zraf4ocowk8w@mail.elegosoft.com> <35F93BA7-A05C-4633-89F0-211C5C0256EA@hotmail.com> <20090629110826.mkugfxs884c0owcc@mail.elegosoft.com> <20090701184824.6oeqk8cdbggw8owc@mail.elegosoft.com> <20090702082756.e5lkauyzfo44000k@mail.elegosoft.com> <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> Message-ID: <20090702150816.GC21089@topoi.pooq.com> On Thu, Jul 02, 2009 at 12:35:33PM +0200, Olaf Wagner wrote: > Quoting Jay : > > >Olaf, the ws packages contain source and unshipped outputs, right? > >What do you think is the point of these archives vs. binary-only and > > source-only archives? I have ideas but I don't want to lead you. > > The idea was to reduce the number of packages, as M3 does not > really support the separation of source and derived files for binary > packages. So why not just enrich the source with just the products > needed for shipping? This is sort of the smallest supported _M3_-binary > package. > > Both system-dependent source and binary packages can be based on the > same collection of ws packages. > > Traditionally CM3 offered only sources packages except for the minimal > installation archive. There were lots of problems with > > o people understanding how to compile the source and > o actual compilation errors due to miscellaneous causes > > People wanted something that is easy to install (without using lots > of complex scripts). So I extended the standard cm3 builder so it can > be used for such an installation. Just a point of interest. Debian has a number of apparently proprietary packages -- such as the one for nvidia drivers. What they do is, during installation, connect to the nvidia web site to download the driver, then install the result of downloading. So a significane amount of very package-dependent work can be done during installation -- such as compiling. It may not be in the spirit of binary packages, but can be made to work automatically. What this doesn't do is enable multiple binary packages to be built from a single source -- which Debian also does frmo time to time, but at headquarters, not in apt or aptitude. > > These are exactly the ws archives. M3 source and derived files which > are needed for shipping an M3 package, but not more. I found that > rather nice. > > > >>core vs. min vs. boot > > > >Yeah I was equating min with boot. > >Still, as to what is "minimal" vs. "useful", not clear. For example, > > "minimal" can be reduced by not allowing for static linking. The > >.sa files add a lot of size. But that is slightly less useful, so > >someone who wants to make standalone programs. > >And min still varies in definition depending on one's prediction of > >the future. > > > >Even then there are multiple definitions here: > > boot for the current matching release > > or boot for the next release? > > > >If it is for the matching release, no problem predicting the future, > > it is just the assembly code for cm3, and no provision for creating > > a package store with any contents, until user also gets source and > >builds it. I have in mind the old 3.6 release form, though we can't > >quite emulate it, now that the builder is in M3 and not C. > > > >I'd like to look into this cross building of boot/assembly releases, > > though first some other things.. > > The whole cross-compilation topic is not really relevant for a > release IMO. There are very few people who actually want to do > such things ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hosking at cs.purdue.edu Thu Jul 2 17:43:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:43:35 -0400 Subject: [M3devel] Error in building cm3 Message-ID: I've just updated m3-sys/cm3 and now get the following error when building. What gives? --- building in SOLgnu --- ignoring ../src/m3overrides "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: undefined variable: ROOT --procedure-- -line- -file--- include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile 5 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/ SOLgnu/m3make.args Fatal Error: package build failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 17:49:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Message-ID: Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. From hosking at cs.purdue.edu Thu Jul 2 17:51:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:51:30 -0400 Subject: [M3devel] UnixLink.c Message-ID: It seems fundamentally broken to me that m3-sys/cm3 should be doing all this copying of UnixLink just so some previous m3core can be linked to. Surely, when bootstrapping you need to compile a *new* m3core against which cm3 wil link. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 17:54:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:54:51 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: If I define ROOT then I get the following error. I think this all needs reverting! --- building in SOLgnu --- ignoring ../src/m3overrides "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ Common/UnixLink.c" to "./UnixLink.c": errno=2 --procedure-- -line- -file--- cp_if -- include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/ SOLgnu/m3make.args Fatal Error: package build failed n On 2 Jul 2009, at 11:49, Tony Hosking wrote: > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 18:19:03 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:19:03 +0000 Subject: [M3devel] UnixLink.c In-Reply-To: References: Message-ID: > Surely, when bootstrapping you need to > compile a *new* m3core against which cm3 wil link. Nope. As long as we have those "release" tinderbox builds that build from 5.4 m3core... Remove that requirement and I'd gladly clean this up. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:51:30 -0400 > Subject: [M3devel] UnixLink.c > > It seems fundamentally broken to me that m3-sys/cm3 should be doing all this copying of UnixLink just so some previous m3core can be linked to. Surely, when bootstrapping you need to compile a *new* m3core against which cm3 wil link. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > From jay.krell at cornell.edu Thu Jul 2 18:19:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:19:49 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: > Seems broken to me to depend on > the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > From jay.krell at cornell.edu Thu Jul 2 18:21:07 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:21:07 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Are you up to date in m3-libs/m3core? Lots of builds have succeeded with this.. It isn't great, but that requirement to build from previous 5.4 release.. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Thu, 2 Jul 2009 11:54:51 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > If I define ROOT then I get the following error. I think this all needs reverting! > > --- building in SOLgnu --- > > ignoring ../src/m3overrides > > "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/Common/UnixLink.c" to "./UnixLink.c": errno=2 > > --procedure-- -line- -file--- > cp_if -- > include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile > 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > > Fatal Error: package build failed > n > > On 2 Jul 2009, at 11:49, Tony Hosking wrote: > > Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. > > From hosking at cs.purdue.edu Thu Jul 2 18:40:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 12:40:18 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: I'm not talking about m3overrides. That is a arguably a special- purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: > >> Seems broken to me to depend on >> the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 18:42:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 12:42:52 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Whether or not I am up-to-date I dislike the whole ROOT dependence for standard builds! On 2 Jul 2009, at 12:21, Jay wrote: > > Are you up to date in m3-libs/m3core? > Lots of builds have succeeded with this.. > It isn't great, but that requirement to build from previous 5.4 > release.. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 2 Jul 2009 11:54:51 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ROOT >> >> If I define ROOT then I get the following error. I think this all >> needs reverting! >> >> --- building in SOLgnu --- >> >> ignoring ../src/m3overrides >> >> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: >> quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ >> Common/UnixLink.c" to "./UnixLink.c": errno=2 >> >> --procedure-- -line- -file--- >> cp_if -- >> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >> m3makefile >> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >> >> Fatal Error: package build failed >> n >> >> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as >> it sets that structure in stone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 18:55:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:55:16 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: As long as there is a need to work with older m3core, there will be hacks.. This stuff provides a significant value. Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > From jay.krell at cornell.edu Thu Jul 2 19:13:05 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 17:13:05 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Btw, I think setting an environment variable that points to the root of the source tree is a pretty small cost to pay, for almost anything. ROOT is a bit generic I realize. It is worse to be copying files around, I admit, and I'm doing that too. Another option is to copy /and/ commit the files, perhaps to sysutils, since we don't have to work with an old sysutils. This is the same sort of problem, you'll recall, that plagued making waitpid users not sleep() on pthreads platforms. There are still small hacks in place for that -- pretty small now, like, assuming we are on pthreads and not sleeping, to the detriment of user threads implementations. CM3_ROOT should work, but that might depend on your config file. I am strongly tempted to have cm3 poke around in the CVS directories and figure it out itself, as so many builds are run with .sh code that does roughly that. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ROOT > Date: Thu, 2 Jul 2009 16:55:16 +0000 > > > As long as there is a need to work with older m3core, there will be hacks.. > This stuff provides a significant value. > Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. > > > With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. > > As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 12:40:18 -0400 >> >> I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 2 Jul 2009, at 12:19, Jay wrote: >> >> >> Seems broken to me to depend on >> the source directory structure >> >> Like m3overrides? But yes, I agree. >> m3overrides seems broken too. >> >> - Jay >> >> >> >> >> >> >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> >> From jay.krell at cornell.edu Thu Jul 2 19:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 17:14:43 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: [truncated..] ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ROOT > Date: Thu, 2 Jul 2009 17:13:05 +0000 > > > Btw, I think setting an environment variable that points to the root of the source tree is a pretty small cost to pay, for almost anything. > ROOT is a bit generic I realize. > > > It is worse to be copying files around, I admit, and I'm doing that too. > Another option is to copy /and/ commit the files, perhaps to sysutils, since we don't have to work with an old sysutils. This is the same sort of problem, you'll recall, that plagued making waitpid users not sleep() on pthreads platforms. There are still small hacks in place for that -- pretty small now, like, assuming we are on pthreads and not sleeping, to the detriment of user threads implementations. > > > CM3_ROOT should work, but that might depend on your config file. > > I am strongly tempted to have cm3 poke around in the CVS directories and figure it out itself, as so many builds are run with .sh code that does roughly that. > > - Jay > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 16:55:16 +0000 >> >> >> As long as there is a need to work with older m3core, there will be hacks.. >> This stuff provides a significant value. >> Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >> >> >> With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. >> >> As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. >> >> >> - Jay >> >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>> >>> I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 2 Jul 2009, at 12:19, Jay wrote: >>> >>> >>> Seems broken to me to depend on >>> the source directory structure >>> >>> Like m3overrides? But yes, I agree. >>> m3overrides seems broken too. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>> Subject: [M3devel] ROOT >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as it >>> sets that structure in stone. >>> >>> >>> From hosking at cs.purdue.edu Thu Jul 2 19:47:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:47:44 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> On 2 Jul 2009, at 12:55, Jay wrote: > As long as there is a need to work with older m3core, there will be > hacks.. But why would you compile a new cm3 with an old m3core? > This stuff provides a significant value. > Before, the runpaths recorded would be a directory per dependent > shared object -- the directory in the package store. And the > runpaths were not machine portable -- if you install to a different > location, which is debatable, maybe everyone should be stuck with / > usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > With the hard links, people don't have to set LD_LIBRARY_PATH and > everyone can pick their own install location. Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? > As well the temporary staging location for a distribution is not > recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but / > tmp/something. I'd really like to hear opinions on this from others. > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 12:40:18 -0400 >> >> I'm not talking about m3overrides. That is a arguably a special- >> purpose hack. We shouldn't layer a hack into the *normal* build >> process. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 2 Jul 2009, at 12:19, Jay wrote: >> >> >> Seems broken to me to depend on >> the source directory structure >> >> Like m3overrides? But yes, I agree. >> m3overrides seems broken too. >> >> - Jay >> >> >> >> >> >> >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> >> From hosking at cs.purdue.edu Thu Jul 2 19:51:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:51:00 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <314CD2AE-A9E0-4D23-BDEC-DFD776DB8FB7@cs.purdue.edu> On 2 Jul 2009, at 13:13, Jay wrote: > Btw, I think setting an environment variable that points to the root > of the source tree is a pretty small cost to pay, for almost anything. But, again, this hardcodes the source tree structure into the configuration files, which I really hate. > ROOT is a bit generic I realize. > > > It is worse to be copying files around, I admit, and I'm doing that > too. Right. > Another option is to copy /and/ commit the files, perhaps to > sysutils, since we don't have to work with an old sysutils. This is > the same sort of problem, you'll recall, that plagued making waitpid > users not sleep() on pthreads platforms. There are still small hacks > in place for that -- pretty small now, like, assuming we are on > pthreads and not sleeping, to the detriment of user threads > implementations. > > > CM3_ROOT should work, but that might depend on your config file. > > I am strongly tempted to have cm3 poke around in the CVS directories > and figure it out itself, as so many builds are run with .sh code > that does roughly that. Perhaps you can step back and provide a high-level rationale for what is needed, and how best to accomplish it. I've lost the big picture here. > > - Jay > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 16:55:16 +0000 >> >> >> As long as there is a need to work with older m3core, there will be >> hacks.. >> This stuff provides a significant value. >> Before, the runpaths recorded would be a directory per dependent >> shared object -- the directory in the package store. And the >> runpaths were not machine portable -- if you install to a different >> location, which is debatable, maybe everyone should be stuck with / >> usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >> >> >> With the hard links, people don't have to set LD_LIBRARY_PATH and >> everyone can pick their own install location. >> >> As well the temporary staging location for a distribution is not >> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >> but /tmp/something. >> >> >> - Jay >> >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>> >>> I'm not talking about m3overrides. That is a arguably a special- >>> purpose hack. We shouldn't layer a hack into the *normal* build >>> process. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 2 Jul 2009, at 12:19, Jay wrote: >>> >>> >>> Seems broken to me to depend on >>> the source directory structure >>> >>> Like m3overrides? But yes, I agree. >>> m3overrides seems broken too. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>> Subject: [M3devel] ROOT >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as it >>> sets that structure in stone. >>> >>> >>> From hosking at cs.purdue.edu Thu Jul 2 19:51:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:51:36 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> PS I don't see the truncated e-mails when I get them -- must be something broken on your end. On 2 Jul 2009, at 13:14, Jay wrote: > > [truncated..] > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 17:13:05 +0000 >> >> >> Btw, I think setting an environment variable that points to the >> root of the source tree is a pretty small cost to pay, for almost >> anything. >> ROOT is a bit generic I realize. >> >> >> It is worse to be copying files around, I admit, and I'm doing that >> too. >> Another option is to copy /and/ commit the files, perhaps to >> sysutils, since we don't have to work with an old sysutils. This is >> the same sort of problem, you'll recall, that plagued making >> waitpid users not sleep() on pthreads platforms. There are still >> small hacks in place for that -- pretty small now, like, assuming >> we are on pthreads and not sleeping, to the detriment of user >> threads implementations. >> >> >> CM3_ROOT should work, but that might depend on your config file. >> >> I am strongly tempted to have cm3 poke around in the CVS >> directories and figure it out itself, as so many builds are run >> with .sh code that does roughly that. >> >> - Jay >> >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 16:55:16 +0000 >>> >>> >>> As long as there is a need to work with older m3core, there will >>> be hacks.. >>> This stuff provides a significant value. >>> Before, the runpaths recorded would be a directory per dependent >>> shared object -- the directory in the package store. And the >>> runpaths were not machine portable -- if you install to a >>> different location, which is debatable, maybe everyone should be >>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >>> >>> >>> With the hard links, people don't have to set LD_LIBRARY_PATH and >>> everyone can pick their own install location. >>> >>> As well the temporary staging location for a distribution is not >>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >>> but /tmp/something. >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>>> CC: m3devel at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: [M3devel] ROOT >>>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>>> >>>> I'm not talking about m3overrides. That is a arguably a special- >>>> purpose hack. We shouldn't layer a hack into the *normal* build >>>> process. >>>> >>>> >>>> Antony Hosking | Associate Professor | Computer Science | Purdue >>>> University >>>> 305 N. University Street | West Lafayette | IN 47907 | USA >>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>>> >>>> >>>> >>>> >>>> On 2 Jul 2009, at 12:19, Jay wrote: >>>> >>>> >>>> Seems broken to me to depend on >>>> the source directory structure >>>> >>>> Like m3overrides? But yes, I agree. >>>> m3overrides seems broken too. >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: m3devel at elegosoft.com >>>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>>> Subject: [M3devel] ROOT >>>> >>>> Where did variable ROOT come from? Do I really need to define it? >>>> Seems broken to me to depend on the source directory structure as >>>> it >>>> sets that structure in stone. >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 19:53:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:53:07 -0400 Subject: [M3devel] ROOT In-Reply-To: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> Message-ID: <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> That sounds plausible. Is there anything in the current setup that depends on the .so files being in pkg instead of lib? On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > How about we put .so files only in lib and not in pkg? Or symlink > from pkg to lib instead of how it used to be the other way around? > Those would also fix all this. > > - Jay (phone) > > On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> >> Are you up to date in m3-libs/m3core? >> Lots of builds have succeeded with this.. >> It isn't great, but that requirement to build from previous 5.4 >> release.. >> >> - Jay >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 2 Jul 2009 11:54:51 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] ROOT >>> >>> If I define ROOT then I get the following error. I think this all >>> needs reverting! >>> >>> --- building in SOLgnu --- >>> >>> ignoring ../src/m3overrides >>> >>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line >>> 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/ >>> unix/Common/UnixLink.c" to "./UnixLink.c": errno=2 >>> >>> --procedure-- -line- -file--- >>> cp_if -- >>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >>> m3makefile >>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >>> >>> Fatal Error: package build failed >>> n >>> >>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as >>> it sets that structure in stone. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 2 20:04:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Jul 2009 20:04:36 +0200 Subject: [M3devel] ROOT In-Reply-To: <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> Message-ID: <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Quoting Tony Hosking : > That sounds plausible. Is there anything in the current setup that > depends on the .so files being in pkg instead of lib? I don't think so offhand. But I must admit that I've lost the overview in this area, too :-/ Olaf > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > >> How about we put .so files only in lib and not in pkg? Or symlink >> from pkg to lib instead of how it used to be the other way around? >> Those would also fix all this. >> >> - Jay (phone) >> >> On Jul 2, 2009, at 9:21 AM, Jay wrote: >> >>> >>> Are you up to date in m3-libs/m3core? >>> Lots of builds have succeeded with this.. >>> It isn't great, but that requirement to build from previous 5.4 release.. >>> >>> - Jay >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] ROOT >>>> >>>> If I define ROOT then I get the following error. I think this all >>>> needs reverting! >>>> >>>> --- building in SOLgnu --- >>>> >>>> ignoring ../src/m3overrides >>>> >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line >>>> 12: quake runtime error: unable to copy >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to >>>> "./UnixLink.c": errno=2 >>>> >>>> --procedure-- -line- -file--- >>>> cp_if -- >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >>>> >>>> Fatal Error: package build failed >>>> n >>>> >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >>>> >>>> Where did variable ROOT come from? Do I really need to define it? >>>> Seems broken to me to depend on the source directory structure >>>> as it sets that structure in stone. >>>> >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 2 20:09:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 11:09:40 -0700 Subject: [M3devel] ROOT In-Reply-To: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> Message-ID: <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> The ones sent directly to people aren't truncated, only when they go through m3devel. - Jay (phone) On Jul 2, 2009, at 10:51 AM, Tony Hosking wrote: > PS I don't see the truncated e-mails when I get them -- must be > something broken on your end. > > On 2 Jul 2009, at 13:14, Jay wrote: > >> >> [truncated..] >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 17:13:05 +0000 >>> >>> >>> Btw, I think setting an environment variable that points to the >>> root of the source tree is a pretty small cost to pay, for almost >>> anything. >>> ROOT is a bit generic I realize. >>> >>> >>> It is worse to be copying files around, I admit, and I'm doing >>> that too. >>> Another option is to copy /and/ commit the files, perhaps to >>> sysutils, since we don't have to work with an old sysutils. This >>> is the same sort of problem, you'll recall, that plagued making >>> waitpid users not sleep() on pthreads platforms. There are still >>> small hacks in place for that -- pretty small now, like, assuming >>> we are on pthreads and not sleeping, to the detriment of user >>> threads implementations. >>> >>> >>> CM3_ROOT should work, but that might depend on your config file. >>> >>> I am strongly tempted to have cm3 poke around in the CVS >>> directories and figure it out itself, as so many builds are run >>> with .sh code that does roughly that. >>> >>> - Jay >>> >>> >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] ROOT >>>> Date: Thu, 2 Jul 2009 16:55:16 +0000 >>>> >>>> >>>> As long as there is a need to work with older m3core, there will >>>> be hacks.. >>>> This stuff provides a significant value. >>>> Before, the runpaths recorded would be a directory per dependent >>>> shared object -- the directory in the package store. And the >>>> runpaths were not machine portable -- if you install to a >>>> different location, which is debatable, maybe everyone should be >>>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >>>> >>>> >>>> With the hard links, people don't have to set LD_LIBRARY_PATH and >>>> everyone can pick their own install location. >>>> >>>> As well the temporary staging location for a distribution is not >>>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >>>> but /tmp/something. >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ________________________________ >>>>> CC: m3devel at elegosoft.com >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Subject: Re: [M3devel] ROOT >>>>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>>>> >>>>> I'm not talking about m3overrides. That is a arguably a special- >>>>> purpose hack. We shouldn't layer a hack into the *normal* build >>>>> process. >>>>> >>>>> >>>>> Antony Hosking | Associate Professor | Computer Science | Purdue >>>>> University >>>>> 305 N. University Street | West Lafayette | IN 47907 | USA >>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>>>> >>>>> >>>>> >>>>> >>>>> On 2 Jul 2009, at 12:19, Jay wrote: >>>>> >>>>> >>>>> Seems broken to me to depend on >>>>> the source directory structure >>>>> >>>>> Like m3overrides? But yes, I agree. >>>>> m3overrides seems broken too. >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>>>> Subject: [M3devel] ROOT >>>>> >>>>> Where did variable ROOT come from? Do I really need to define it? >>>>> Seems broken to me to depend on the source directory structure >>>>> as it >>>>> sets that structure in stone. >>>>> >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Thu Jul 2 20:31:45 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 14:31:45 -0400 Subject: [M3devel] ROOT In-Reply-To: <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> Message-ID: <4A4CC4CE.1E75.00D7.1@scires.com> I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Thu Jul 2 20:41:27 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:41:27 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: Before I explain, more options: copy and commit the source to cm3 is viable heck, use a relative instead of absolute from ROOT go back to the old way (I'll explain) There is also the option to relink or "fixup" upon ship and/or install. Some platforms have a "fixup" utility for exactly "these reasons". MacOS X has one. The question is: How does program foo find libbar.so? At runtime. How does libbar.so find libfoo.so? There are a bewildering array of choices. They are combinable. It varies somewhat from platform by platform, but not much really. The main options are: 1: A full path written into program foo or libbar pointing to e.g. /usr/lib/libfoo.so. Actually this is usually separate libfoo.so and a list of directories that apply to all .so files. There isn't generally a matching up of directory to file, I think, but a "search path" aka "run path". 2: A relative path written into program foo or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. Again, the directories are split from the files. MacOS X doesn't have $ORIGIN by that name, but it has three similar things, like @executable_path. @executable_path goes way back and is presumably relative to the primary main executable. There are two other similar options. One is new in 10.5. Presumably one is relative to the reference. And maybe one is some concatenation of all directories anything found in so far? I don't know. The documenation was not clear to me. NetBSD prior to 5.0 doesn't have $ORIGIN. NT searches $PATH always. We put the .dlls in bin. Cygwin same. Approximately all other systems seem to support about the same $ORIGIN feature: OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?) The MacOS X feature is close enough to lump in. 3: Search $LD_LIBRARY_PATH or similar. This has a few different names. LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. Now, our historical implementation was - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, a path for every dependency The file formats are generally such that there are leaf file names separate from an array of directories to look in. A "normal" non-Modula-3 program would generally I assume have a prety small such array of directories. A "normal" Modula-3 program would have a fairly large array. As well, doing builds for distribution would often leave you with /tmp/cm3 which is a possible security problem. This definitely did occur. Now, again, there are many options, and they can be combined. Portability is perhaps a concern, but perhaps not so much, given today's landscape. Now, if we are to use relative paths, well, my understanding is that the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib, and not /usr/local/cm3/pkg/foo/linux etc. This way, files in lib and bin can point to $ORIGIN/../lib. Now, keep in mind, that unshipped binaries sometimes people like to work, as well, perhaps also programs (not shared libraies, as far as I know) buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. I know cm3 sits in there, though that copy isn't used. I make no account for binaries buried in the package store. I do make some account for unshipped binaries. By default the run paths we are recording in current config files are $ORIGIN/../lib:/usr/local/cm3/lib Not a bunch of paths into pkg, just two entries. The "security" issue still is present by default. But the run path is "prettier" and probably more efficient. When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3). This is controled by an environment variable, which I set in Olaf's scripts, but oops I think I set it too late. I'll fix that very very soon. To recap: - full paths - relative paths from $ORIGIN - LD_LIBRARY_PATH They each have advantages and disadvantages. $ORIGIN provides for a "movable" install. I can install to /usr/local/cm3, you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH. However if I want to move just some of the files, not the whole binary tree together, then $ORIGIN breaks down. If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do. You are left with full paths or LD_LIBRARY_PATH. Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such. Look on birch for example, it is /usr/local/cm3/lib. That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there. This demonstrated another problem in this area! $ORIGIN keeps things more tightly together, which you often want, sometimes might not not. LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not. I figure tightly point is the more common, but imagine if you just want to replace one file. Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install this way.) So, here now I'm rambling. I've laid out the options and /some/ of the disadvantages/advantages. There is no perfect solution, and the various solutions are combinable. I find combining them though, I start to get confused. Because you end up in a "probing" situation and you start wondering which supercedes which, and you just hope there aren't any "duplicates" so that the probe order is mostly moot (assuming there remain no duplicates). Somewhat clear? You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and investigate the various options and their effects. Solaris has a very nice and verbose ldd form. Now, the files in pkg. I consider it somewhat philosophically significant that "everything is in pkg". There is a well structured "repository" not a randomly organized bunch of files. I think. Maybe this is just a suggestion? You know, if they are hardlinks and we don't really use the ones in pkg, is there a point? Or, on the other hand, is the philosophy a big deal and we should go back to lib symlinking to pkg to appease the philosophy? "ship/install" certainly "likes" to put things in pkg. I don't think the option of using lib and not pkg is doable without builder changes. But that is doable. A few other folks here did pipe up some on this in the recent past and I think there was kinda sorta consensus that the old ways were not great (particularly 1) the big runpath 2) the runpath into /tmp) and the new ways maybe better, but I admit there was no clear consensus. I acted somewhat unilaterally. You know, I'm impatient and arrogant so... and Tinderbox is there to cause some restraint. There was definitely pushback on wanting unshipped binaries to keep working, which they largely do as a result of the discussion/pushback. As well, any unshipped binaries that we know we use in the build, like PklFonts, stubgen, m3bundle, we build standalone, to evade/avoid problems here, since $ORIGIN/../lib won't work and the full paths are meant to be omitted. I consider this not great. I think, really, we should be able to dynamically link everything really, including cm3. I don't think we should static link just to make up for the need for a backup. There are plenty of backups available and you can make plenty more. However this will have to wait and probably take more arguing and maybe demonstration of its viability. I will require some work to make work anyway. At one point I was confused about the need for static linking so accepted it strongly. Now I don't see it. If you just need backups, again, they exist, and you can make more. Static linking isn't imho a substitute for backups. There are technical problems to be solved though. Could be that these issues are related though. If your backup might load the wrong m3core.so too easily, making it not a very reliable backup, static linking could mitigate that. But $origin seems like a good mitigation. I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath. That way you can just put everything in one messy but easier to move/copy directory. - Jay > Date: Thu, 2 Jul 2009 20:04:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > Quoting Tony Hosking : > > > That sounds plausible. Is there anything in the current setup that > > depends on the .so files being in pkg instead of lib? > > I don't think so offhand. But I must admit that I've lost the overview > in this area, too :-/ > > Olaf > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > >> How about we put .so files only in lib and not in pkg? Or symlink > >> from pkg to lib instead of how it used to be the other way around? > >> Those would also fix all this. > >> > >> - Jay (phone) > >> > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> > >>> > >>> Are you up to date in m3-libs/m3core? > >>> Lots of builds have succeeded with this.. > >>> It isn't great, but that requirement to build from previous 5.4 release.. > >>> > >>> - Jay > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] ROOT > >>>> > >>>> If I define ROOT then I get the following error. I think this all > >>>> needs reverting! > >>>> > >>>> --- building in SOLgnu --- > >>>> > >>>> ignoring ../src/m3overrides > >>>> > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > >>>> 12: quake runtime error: unable to copy > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > >>>> "./UnixLink.c": errno=2 > >>>> > >>>> --procedure-- -line- -file--- > >>>> cp_if -- > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > >>>> > >>>> Fatal Error: package build failed > >>>> n > >>>> > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > >>>> > >>>> Where did variable ROOT come from? Do I really need to define it? > >>>> Seems broken to me to depend on the source directory structure > >>>> as it sets that structure in stone. > >>>> > >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:48:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:48:00 +0000 Subject: [M3devel] ROOT In-Reply-To: <4A4CC4CE.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I'm completely agree that ROOT is too generic for an environment variable and it NOT required. It IS a quake variable though, and has long been. Nothing new there. At least if you ever use overrides. CM3_ROOT is in fact the other name. There are also quake variables INSTALLROOT and/or INSTALL_ROOT, I get those confused, and the environment variable CM3_INSTALL. I'm not a huge fan of the exact names actually, but they all/mostly were already there. I would have liked CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. I find ROOT and CM3_ROOT too ambiguous. But again, ROOT is quite old, to refer to the source and INSTALL_ROOT or INSTALLROOT is quite old to refer to the install. Hopefully my other mail will help clear this up. I agree this is all not easy to communicate. To some extent I just have to depend on people knowing that "How a file finds the .so files it uses?" Is a well known long standing dilemna and if you search the web you can find many people trying to explain aspects of it. Maybe I should put together some examples. However, I think I did. I think the ChangeLog explains it well. Let me check. no..must have been somewhere else. Anyway, search the web for $origin, ldd, -runpath, etc.... Try wading through the Apple, Sun, GNU/Linux ld man pages. They aren't pretty, I grant. I'll try to put together some examples maybe soon, maybe. Solaris has the nicer more verbose ldd and I'll be away over the weekend so no Solaris. I'd also like to do other Modula-3 work: 64 bit file sizes on all platforms I'm at least going to try. This might cascade too far and break a lot of things, since INTEGER and LONGINT cannot be freely intermixed, you can't even assign an INTEGER to a LONGINT! Merge gcc-interix with gcc. It turns out this is quite small. Enable the "portable runpaths" in Olaf's scripts (related to all this). I put the lines in slightly too far down in the code, oops. - Jay Date: Thu, 2 Jul 2009 14:31:45 -0400 From: rcolebur at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:51:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:51:22 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: darnit I need to be more careful. program -- not a shared library binary -- program or shared library in some contexts, but I used it below also to mean program shared library -- .dll, .so, etc. "I make no account for binaries in the pkg store" -- I meant programs. Darn I need to write this better...hopefully some of it will come through... - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 18:41:27 +0000 Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Before I explain, more options: copy and commit the source to cm3 is viable heck, use a relative instead of absolute from ROOT go back to the old way (I'll explain) There is also the option to relink or "fixup" upon ship and/or install. Some platforms have a "fixup" utility for exactly "these reasons". MacOS X has one. The question is: How does program foo find libbar.so? At runtime. How does libbar.so find libfoo.so? There are a bewildering array of choices. They are combinable. It varies somewhat from platform by platform, but not much really. The main options are: 1: A full path written into program foo or libbar pointing to e.g. /usr/lib/libfoo.so. Actually this is usually separate libfoo.so and a list of directories that apply to all .so files. There isn't generally a matching up of directory to file, I think, but a "search path" aka "run path". 2: A relative path written into program foo or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. Again, the directories are split from the files. MacOS X doesn't have $ORIGIN by that name, but it has three similar things, like @executable_path. @executable_path goes way back and is presumably relative to the primary main executable. There are two other similar options. One is new in 10.5. Presumably one is relative to the reference. And maybe one is some concatenation of all directories anything found in so far? I don't know. The documenation was not clear to me. NetBSD prior to 5.0 doesn't have $ORIGIN. NT searches $PATH always. We put the .dlls in bin. Cygwin same. Approximately all other systems seem to support about the same $ORIGIN feature: OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?) The MacOS X feature is close enough to lump in. 3: Search $LD_LIBRARY_PATH or similar. This has a few different names. LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. Now, our historical implementation was - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, a path for every dependency The file formats are generally such that there are leaf file names separate from an array of directories to look in. A "normal" non-Modula-3 program would generally I assume have a prety small such array of directories. A "normal" Modula-3 program would have a fairly large array. As well, doing builds for distribution would often leave you with /tmp/cm3 which is a possible security problem. This definitely did occur. Now, again, there are many options, and they can be combined. Portability is perhaps a concern, but perhaps not so much, given today's landscape. Now, if we are to use relative paths, well, my understanding is that the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib, and not /usr/local/cm3/pkg/foo/linux etc. This way, files in lib and bin can point to $ORIGIN/../lib. Now, keep in mind, that unshipped binaries sometimes people like to work, as well, perhaps also programs (not shared libraies, as far as I know) buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. I know cm3 sits in there, though that copy isn't used. I make no account for binaries buried in the package store. I do make some account for unshipped binaries. By default the run paths we are recording in current config files are $ORIGIN/../lib:/usr/local/cm3/lib Not a bunch of paths into pkg, just two entries. The "security" issue still is present by default. But the run path is "prettier" and probably more efficient. When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3). This is controled by an environment variable, which I set in Olaf's scripts, but oops I think I set it too late. I'll fix that very very soon. To recap: - full paths - relative paths from $ORIGIN - LD_LIBRARY_PATH They each have advantages and disadvantages. $ORIGIN provides for a "movable" install. I can install to /usr/local/cm3, you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH. However if I want to move just some of the files, not the whole binary tree together, then $ORIGIN breaks down. If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do. You are left with full paths or LD_LIBRARY_PATH. Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such. Look on birch for example, it is /usr/local/cm3/lib. That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there. This demonstrated another problem in this area! $ORIGIN keeps things more tightly together, which you often want, sometimes might not not. LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not. I figure tightly point is the more common, but imagine if you just want to replace one file. Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install this way.) So, here now I'm rambling. I've laid out the options and /some/ of the disadvantages/advantages. There is no perfect solution, and the various solutions are combinable. I find combining them though, I start to get confused. Because you end up in a "probing" situation and you start wondering which supercedes which, and you just hope there aren't any "duplicates" so that the probe order is mostly moot (assuming there remain no duplicates). Somewhat clear? You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and investigate the various options and their effects. Solaris has a very nice and verbose ldd form. Now, the files in pkg. I consider it somewhat philosophically significant that "everything is in pkg". There is a well structured "repository" not a randomly organized bunch of files. I think. Maybe this is just a suggestion? You know, if they are hardlinks and we don't really use the ones in pkg, is there a point? Or, on the other hand, is the philosophy a big deal and we should go back to lib symlinking to pkg to appease the philosophy? "ship/install" certainly "likes" to put things in pkg. I don't think the option of using lib and not pkg is doable without builder changes. But that is doable. A few other folks here did pipe up some on this in the recent past and I think there was kinda sorta consensus that the old ways were not great (particularly 1) the big runpath 2) the runpath into /tmp) and the new ways maybe better, but I admit there was no clear consensus. I acted somewhat unilaterally. You know, I'm impatient and arrogant so... and Tinderbox is there to cause some restraint. There was definitely pushback on wanting unshipped binaries to keep working, which they largely do as a result of the discussion/pushback. As well, any unshipped binaries that we know we use in the build, like PklFonts, stubgen, m3bundle, we build standalone, to evade/avoid problems here, since $ORIGIN/../lib won't work and the full paths are meant to be omitted. I consider this not great. I think, really, we should be able to dynamically link everything really, including cm3. I don't think we should static link just to make up for the need for a backup. There are plenty of backups available and you can make plenty more. However this will have to wait and probably take more arguing and maybe demonstration of its viability. I will require some work to make work anyway. At one point I was confused about the need for static linking so accepted it strongly. Now I don't see it. If you just need backups, again, they exist, and you can make more. Static linking isn't imho a substitute for backups. There are technical problems to be solved though. Could be that these issues are related though. If your backup might load the wrong m3core.so too easily, making it not a very reliable backup, static linking could mitigate that. But $origin seems like a good mitigation. I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath. That way you can just put everything in one messy but easier to move/copy directory. - Jay > Date: Thu, 2 Jul 2009 20:04:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > Quoting Tony Hosking : > > > That sounds plausible. Is there anything in the current setup that > > depends on the .so files being in pkg instead of lib? > > I don't think so offhand. But I must admit that I've lost the overview > in this area, too :-/ > > Olaf > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > >> How about we put .so files only in lib and not in pkg? Or symlink > >> from pkg to lib instead of how it used to be the other way around? > >> Those would also fix all this. > >> > >> - Jay (phone) > >> > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> > >>> > >>> Are you up to date in m3-libs/m3core? > >>> Lots of builds have succeeded with this.. > >>> It isn't great, but that requirement to build from previous 5.4 release.. > >>> > >>> - Jay > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] ROOT > >>>> > >>>> If I define ROOT then I get the following error. I think this all > >>>> needs reverting! > >>>> > >>>> --- building in SOLgnu --- > >>>> > >>>> ignoring ../src/m3overrides > >>>> > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > >>>> 12: quake runtime error: unable to copy > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > >>>> "./UnixLink.c": errno=2 > >>>> > >>>> --procedure-- -line- -file--- > >>>> cp_if -- > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > >>>> > >>>> Fatal Error: package build failed > >>>> n > >>>> > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > >>>> > >>>> Where did variable ROOT come from? Do I really need to define it? > >>>> Seems broken to me to depend on the source directory structure > >>>> as it sets that structure in stone. > >>>> > >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:56:27 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:56:27 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: Here are some good links, other people trying to explain this stuff: http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the Avoiding LD_LIBRARY_PATH: The Options With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. LD_LIBRARY_PATH Seems Useful. What's the Problem? http://blogs.sun.com/rie/entry/hello_there Surfing With a Linker Alien http://blogs.sun.com/rie/entry/tt_ld_library_path_tt LD_LIBRARY_PATH - just say no A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: % ldd -s /usr/bin/date ... find object=libc.so.1; required by /usr/bin/date search path=/opt/ISV/lib (LD_LIBRARY_PATH) If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"` The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) (2004-07-10 22:20:54.0) Permalink Comments [8] Comments: .... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:13:14 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:13:14 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: http://linuxmafia.com/faq/Admin/ld-lib-path.html Why setting LD_LIBRARY_PATH is considered harmful For the following reasons: LD_LIBRARY_PATH is used in preference to any run time or default system linker path. If (God forbid) you had it set to something like /dcs/spod/baduser/lib, if there was a hacked version of libc in that directory (for example) your account could be compromised. It is for this reason that set-uid programs completely ignore LD_LIBRARY_PATH. When code is compiled and depends on this to work, it can cause confusion where different versions of a library are installed in different directories, for example there is a libtiff in /usr/openwin/lib and /usr/local/lib. In this case, the former library is an older one used by some programs that come with Solaris. Sometimes when using precompiled binaries they may have been built with 3rd party libraries in specific locations; ideally code should either ship with the libraries and install into a certain location or link the code as a pre-installation step. Solaris 7 introduces $ORIGIN which allows for a relative library location to be specified at run time (see the Solaris Linker and Libraries Guide). The alternative is to set LD_LIBRARY_PATH on a per-program basis, either as a wrapper program to the real program or a shell alias. Note however, that LD_LIBRARY_PATH may be inherited by programs called by the wrapped one ... http://lists.trolltech.com/qt4-preview-feedback/2005-04/msg00648.html Requiring LD_LIBRARY_PATH is not a good idea imo. It's a variable meant to override defaults, not for the common case. If all packages on ours disks would require this variable hell would break loose. Ask a system administrator. .... different person... Unfortunately rpath is not a solution by itself (although it could be part of the solution). Having rpath point to the build directory is a security hole. It can be part of the solution though ..yet another...shades of things I have said here... Now you may argue that runMyAppUsingQtAndMyLib needs to be re-linked deployment anyway. I agree that's what some programs do or should do (some have even suggested to distribute *.o files and relink them on the target platform using an adequate rpath, but that's a bad idea since the linker may be unpatched and the C++ compiler broken on the target platform). Some users won't relink though. Shouldn't Qt protect them by default? What do you think? http://lists.apple.com/archives/Unix-porting/2005/May/msg00034.html As others have pointed out there is not really an equivalent of LD_LIBRARY_PATH because the whole shared library system is unique to MacOS X/Darwin. I think it is fair to say that if you find yourself using DYLD_LIBRARY_PATH except for testing uninstalled binaries, then you are doing it wrong. Every executable file on Darwin contains the full paths of the libraries against which it was linked, and these are used first by dyld at runtime. They can be changed after linking. (see docs about install_name) So you should never need to specify some odd DYLD_LIBRARY_PATH with a properly installed library wherever it is installed. So now maybe I should search the web for negative comments about $origin? Well, when I try "what is wrong with ld $origin" I again find criticism of LD_LIBRARY_PATH. :) Ok, I admit I didn't look very hard. I'll look more later. So you see, the point is, there is a lot stuff out there discouraging LD_LIBRARY_PATH and encouraging full paths and/or $origin. Including Sun's linker developer(s). Full paths are ok for us, to the symlinks, if we then have full paths within the files. But if we use $origin, then the pkg store bites us. Is some of this making sense? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 18:56:27 +0000 Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Here are some good links, other people trying to explain this stuff: http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the Avoiding LD_LIBRARY_PATH: The Options With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. LD_LIBRARY_PATH Seems Useful. What's the Problem? http://blogs.sun.com/rie/entry/hello_there Surfing With a Linker Alien http://blogs.sun.com/rie/entry/tt_ld_library_path_tt LD_LIBRARY_PATH - just say no A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: % ldd -s /usr/bin/date ... find object=libc.so.1; required by /usr/bin/date search path=/opt/ISV/lib (LD_LIBRARY_PATH) If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"` The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) (2004-07-10 22:20:54.0) Permalink Comments [8] Comments: .... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:23:55 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: [M3devel] ROOT In-Reply-To: <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:30:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:30:22 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: Btw, I must say, that Modula-3 often bucks the trend, often with reason and benefit. However the "trend" has a lot of people behind it, using it, fixing it, making sure it works. The "trend", the popular practice, would include put the files in /usr/local/cm3/lib and not pkg. Or, well, pkg could be an unused copy, but that's fairly pointless and wasteful. My use of hardlinks is not exactly "trendy". But I was kinda sorta not breaking the "pkg philosophy". It's like the putting an extra unused copy in pkg, but without much space wastage (just directory entries) At least then the whole symlink/root thing can go away at least. Though just using a relative path to get the source file or copying and commiting a smaller piece of it, would be ok..if someone wants hardlink primitive in cm3 for some reason still. The runpath won't be huge then also, no matter how all the other debating goes. I need some time to settle down and think about it and /try it out/ but at the moment I'm tempted by the ditching of pkg for .so files and just them in lib. It will require probably new builder and config file changes. Really the current hardlink solution is extremely close to this, but again, also not "trendy". .a/.sa files would remain where they are, in pkg, though, of course, there is "very trendy" precedent against that too. And then, er...what is left in pkg? - Jay From: jay.krell at cornell.edu To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: Re: [M3devel] ROOT >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:37:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:37:45 -0400 Subject: [M3devel] ROOT In-Reply-To: <4A4CC4CE.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I think best would be for Jay to reprise his thinking on why all of this was needed. In general, I oppose hard links on the grounds that they are not trivially migrateable. Better to have relative symbolic links. If we can avoid the need for $origin by installing libraries in a fixed INSTALL_ROOT/lib directory (rather than the current symbolic links approach) then I prefer that. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 14:31, Randy Coleburn wrote: > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:47:23 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:47:23 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I half agree. It'll be a few hours/days, maybe a week, but I'll take a stab at only putting the files in lib. I don't know if it'll be easy or not but I'll try. Therefore no hardlinks. But still $origin. Unless maybe there is consensus that install must be /usr/local/cm3, unless you build/link yourself, then you can chose. And the distribution building will have to be sure to...um...? Be done as root and impact the running system??? No.. Well, distribution building can make it work somehow, by using -rpath /usr/local/cm3/lib, even if ld is pointed at /tmp/cm3/lib/libfoo.so. I can look into that, if there is actually firm consensus against $origin and for full paths, and for taking away user choice of install location...but...but....what about non-admin installs? They have to rebuild? As a non-admin installer on cm3, I can probably live with that, but not sure about others..seems not great. Another option is to link upon install, or "fixup" the paths on systems that can do that without relinking. Again I come back to favoring origin pretty strongly. Hard links seem perfectly migratable..they tar and untar at least.. I get it probably though -- what flags to use to cp? There are too many options, it confuses me. I know hard links can't cross file systems, but often people only hardlink "nearby" files that are the same file system anyway. Hardlinks don't survive on Windows FAT filesystem, probably nobody cares. They work fine on NTFS. Some copy utilities might break them though, yeah, that happens. Full paths not using $origin aren't migratable. - Jay From: hosking at cs.purdue.edu To: rcolebur at scires.com Date: Thu, 2 Jul 2009 15:37:45 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT I think best would be for Jay to reprise his thinking on why all of this was needed. In general, I oppose hard links on the grounds that they are not trivially migrateable. Better to have relative symbolic links. If we can avoid the need for $origin by installing libraries in a fixed INSTALL_ROOT/lib directory (rather than the current symbolic links approach) then I prefer that. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 14:31, Randy Coleburn wrote: I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:48:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:48:14 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> On 2 Jul 2009, at 14:41, Jay wrote: > Before I explain, more options: > > copy and commit the source to cm3 is viable I don't know what this sentence means. > heck, use a relative instead of absolute from ROOT ditto > go back to the old way (I'll explain) I think I understand the shortcomings here but Jay should explain. > There is also the option to relink or "fixup" > upon ship and/or install. Some platforms have a "fixup" > utility for exactly "these reasons". > MacOS X has one. Sounds feasible, but I worry about portability of this approach. > The question is: > > How does program foo find libbar.so? > At runtime. Right. rpaths in the executable should do the trick. > How does libbar.so find libfoo.so? Same again. > There are a bewildering array of choices. > They are combinable. > It varies somewhat from platform by platform, but not much really. Ideally we use the same approach for *all* platforms. So, what do all platforms have in common. > The main options are: > > > 1: A full path written into program foo > or libbar pointing to e.g. /usr/lib/libfoo.so. > Actually this is usually separate libfoo.so and > a list of directories that apply to all .so files. > There isn't generally a matching up of directory to file, > I think, but a "search path" aka "run path". i.e., rpath? > 2: A relative path written into program foo > or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. > Again, the directories are split from the files. Please explain the implications of this w.r. to hard links! I don't want hard links. > MacOS X doesn't have $ORIGIN by that name, but it > has three similar things, like @executable_path. > @executable_path goes way back and is presumably > relative to the primary main executable. Then we should avoid $ORIGIN. Use the linker options to specify rpaths (and if there is need for override use $LD_LIBRARY_PATH. > There are two other similar options. > One is new in 10.5. Presumably one is relative > to the reference. And maybe one is some concatenation > of all directories anything found in so far? I don't know. > The documenation was not clear to me. Again, I'd like to use the same approach on all platforms (except perhaps Windows). > NetBSD prior to 5.0 doesn't have $ORIGIN. A good reason not to use it. > NT searches $PATH always. > We put the .dlls in bin. > Cygwin same. OK, so things work fine there. > Approximately all other systems seem to support about the same > $ORIGIN feature: > OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and > others (Aix? Irix? HP-UX?) > The MacOS X feature is close enough to lump in. > > 3: Search $LD_LIBRARY_PATH or similar. > This has a few different names. > LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. These are fallbacks for the situation when the default installed configuration needs overriding. > Now, our historical implementation was > - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, > a path for every dependency > The file formats are generally such that there are leaf file names > separate from an array of directories to look in. A "normal" > non-Modula-3 program would generally I assume have a prety small > such array of directories. A "normal" Modula-3 program would have > a fairly large array. But if everything goes in INSTALL_ROOT/lib we have only one directory, right? > As well, doing builds for distribution would often leave you with / > tmp/cm3 > which is a possible security problem. This definitely did occur. Surely, building for a distro can build in the right path. Where did / tmp/cm3 come from? If you need to be able to override while building then use $LD_LIBRARY_PATH. > Now, again, there are many options, and they can be combined. > Portability is perhaps a concern, but perhaps not so much, given > today's landscape. Elegance is also a concern. > Now, if we are to use relative paths, well, my understanding is that > the "real" files need to be in relatively few directories, e.g. /usr/ > local/cm3/lib, > and not /usr/local/cm3/pkg/foo/linux etc. I prefer this approach. > This way, files in lib and bin can point to $ORIGIN/../lib. Fair enough. > Now, keep in mind, that unshipped binaries sometimes people like to > work, > as well, perhaps also programs (not shared libraies, as far as I know) > buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. > I know cm3 sits in there, though that copy isn't used. I don't know understand what you are trying to say here. > I make no account for binaries buried in the package store. > > I do make some account for unshipped binaries. > > By default the run paths we are recording in current config files > are > $ORIGIN/../lib:/usr/local/cm3/lib > Not a bunch of paths into pkg, just two entries. > > > The "security" issue still is present by default. > But the run path is "prettier" and probably more efficient. > > > When you build a distribution however, you are expected to omit /usr/ > local/cm3/lib (it might be /tmp/cm3). > This is controled by an environment variable, which I set in Olaf's > scripts, but oops > I think I set it too late. I'll fix that very very soon. The following is a bit rambling for me to respond to in detail. Perhaps someone else should weigh in. > > > To recap: > - full paths > - relative paths from $ORIGIN > - LD_LIBRARY_PATH > > They each have advantages and disadvantages. > $ORIGIN provides for a "movable" install. I can install to /usr/ > local/cm3, > you can install to /opt/cm3. It'll just work. No need to change > LD_LIBRARY_PATH. > > > However if I want to move just some of the files, not the whole > binary tree > together, then $ORIGIN breaks down. > > > If really want one file here, another there, and another somewhere > else, $ORIGIN doesn't do. > You are left with full paths or LD_LIBRARY_PATH. > > > Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or > such. > Look on birch for example, it is /usr/local/cm3/lib. > That tripped me up actually, because, you know, my cm3 is in $HOME/ > cm3 there. > This demonstrated another problem in this area! > $ORIGIN keeps things more tightly together, which you often want, > sometimes might not not. > LD_LIBRARY_PATH lets things be spread around, again, sometimes you > want that, sometimes not. > I figure tightly point is the more common, but imagine if you just > want to replace one file. > Is that reasonable? You replace it by putting it elsewhere? > (Imagine "patching" an install > this way.) > > > So, here now I'm rambling. > I've laid out the options and /some/ of the disadvantages/advantages. > > > There is no perfect solution, and the various solutions are > combinable. > I find combining them though, I start to get confused. > Because you end up in a "probing" situation and you start wondering > which supercedes which, and you just hope there aren't any > "duplicates" > so that the probe order is mostly moot (assuming there remain no > duplicates). > > > Somewhat clear? > > > You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo > or ldd -v or -V foo and > investigate the various options and their effects. Solaris has a > very nice and verbose > ldd form. > > > Now, the files in pkg. > I consider it somewhat philosophically significant that "everything > is in pkg". > There is a well structured "repository" not a randomly organized > bunch of files. > I think. Maybe this is just a suggestion? > You know, if they are hardlinks and we don't really use the ones in > pkg, is > there a point? > > > Or, on the other hand, is the philosophy a big deal and we should go > back to > lib symlinking to pkg to appease the philosophy? > > > "ship/install" certainly "likes" to put things in pkg. > I don't think the option of using lib and not pkg is doable without > builder changes. > But that is doable. > > > A few other folks here did pipe up some on this in the recent past and > I think there was kinda sorta consensus that the old ways were not > great > (particularly 1) the big runpath 2) the runpath into /tmp) > and the new ways maybe better, but I admit there was no clear > consensus. > I acted somewhat unilaterally. You know, I'm impatient and arrogant > so... > and Tinderbox is there to cause some restraint. > > > There was definitely pushback on wanting unshipped binaries to keep > working, > which they largely do as a result of the discussion/pushback. > > > As well, any unshipped binaries that we know we use in the build, > like PklFonts, > stubgen, m3bundle, we build standalone, to evade/avoid problems here, > since $ORIGIN/../lib won't work and the full paths are meant to be > omitted. > I consider this not great. > > I think, really, we should be able to dynamically link everything > really, > including cm3. I don't think we should static link just to make up for > the need for a backup. There are plenty of backups available and you > can > make plenty more. However this will have to wait and probably take > more arguing and maybe demonstration of its viability. > I will require some work to make work anyway. > > > At one point I was confused about the need for static linking so > accepted it strongly. > Now I don't see it. If you just need backups, again, they exist, and > you can make more. > Static linking isn't imho a substitute for backups. > There are technical problems to be solved though. > > Could be that these issues are related though. If your backup might > load the wrong m3core.so too easily, making it not a very reliable > backup, > static linking could mitigate that. But $origin seems like a good > mitigation. > I'm strongly considering add just plain $origin, in addition to > $origin/../lib to runpath. > That way you can just put everything in one messy but easier to move/ > copy directory. > > > - Jay > > > > > > > Date: Thu, 2 Jul 2009 20:04:36 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] ROOT > > > > Quoting Tony Hosking : > > > > > That sounds plausible. Is there anything in the current setup that > > > depends on the .so files being in pkg instead of lib? > > > > I don't think so offhand. But I must admit that I've lost the > overview > > in this area, too :-/ > > > > Olaf > > > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > > > >> How about we put .so files only in lib and not in pkg? Or symlink > > >> from pkg to lib instead of how it used to be the other way > around? > > >> Those would also fix all this. > > >> > > >> - Jay (phone) > > >> > > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > > >> > > >>> > > >>> Are you up to date in m3-libs/m3core? > > >>> Lots of builds have succeeded with this.. > > >>> It isn't great, but that requirement to build from previous > 5.4 release.. > > >>> > > >>> - Jay > > >>> > > >>> ________________________________ > > >>>> From: hosking at cs.purdue.edu > > >>>> To: hosking at cs.purdue.edu > > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] ROOT > > >>>> > > >>>> If I define ROOT then I get the following error. I think this > all > > >>>> needs reverting! > > >>>> > > >>>> --- building in SOLgnu --- > > >>>> > > >>>> ignoring ../src/m3overrides > > >>>> > > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > > >>>> 12: quake runtime error: unable to copy > > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > > >>>> "./UnixLink.c": errno=2 > > >>>> > > >>>> --procedure-- -line- -file--- > > >>>> cp_if -- > > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ > m3makefile > > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > > >>>> > > >>>> Fatal Error: package build failed > > >>>> n > > >>>> > > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > > >>>> > > >>>> Where did variable ROOT come from? Do I really need to define > it? > > >>>> Seems broken to me to depend on the source directory structure > > >>>> as it sets that structure in stone. > > >>>> > > >>>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:52:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:52:38 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: <86309DFE-9D46-4092-AE9D-B94BA88234E8@cs.purdue.edu> On 2 Jul 2009, at 14:48, Jay wrote: > Hopefully my other mail will help clear this up. Jay, it's generally best to confine yourself to one e-mail instead of multiple. My (mental) bandwidth is saturated by the number of e-mails I must read in a day, so I can't keep track of all of yours. > I'd also like to do other Modula-3 work: > 64 bit file sizes on all platforms > I'm at least going to try. This might cascade too far and break > a lot of things, since INTEGER and LONGINT cannot be freely > intermixed, you can't even assign an INTEGER to a LONGINT! You can convert an INTEGER to a LONGINT. It is deliberate that INTEGER and LONGINT be unrelated types, in keeping with the spirit of M3. Implicit C casts are notorious sources of bugs. > Merge gcc-interix with gcc. It turns out this is quite small. > > Enable the "portable runpaths" in Olaf's scripts (related to all > this). > I put the lines in slightly too far down in the code, oops. Olaf, can you help clarify? > > > > - Jay > > Date: Thu, 2 Jul 2009 14:31:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:59:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:59:25 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:59:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:59:50 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> Message-ID: > copy and commit the source to cm3 is viable > I don't know what this sentence means. I don't have to be copying files around in the build order for cm3 to create hard links. I can just copy on my machine and commit to cvs a little bit of code to do it. That isn't nearly as hacky. > heck, use a relative instead of absolute from ROOT > ditto $origin it turns out is very portable. Every system we support except NetBSD 4.0 seems to have it, and even some we don't currently support. And NetBSD 5.0, which already released, has it. And MacOSX is plenty close enough. It is a matter of relative to the executable or the reference, and which OS version you support. I believe newer versions relaly do have $origin by another name, but 10.4 has relative to the executable, which is good enough to me. If you don't use $origin, then people either must install to the one true place, or they must use LD_LIBRARY_PATH, or they must rebuild/relink/fixup themselves. LD_LIBRARY_PATH is widely panned. Having to rebuild seems onerous for most people. Having a choice of where to install? Important? > Right. rpaths in the executable should do the trick. Just in the executable? Shouldn't they somewhat be in the shared libraries? If foo uses libm3 and libm3 uses m3core and foo doesn't use m3core, arguably foo shouldn't mention m3core, only libm3 should. > Ideally we use the same approach for *all* platforms. So, what do all platforms have in common. $origin comes extremely close to that, and provides the benefit that user can specify where to install. > and if there is need for override use $LD_LIBRARY_PATH. But again (I know, I repeated myself, so you did, now I am), this forces any install to non-default location to use LD_LIBRARY_PATH. It is an option. But $origin is also /very/ portable... >> But if everything goes in INSTALL_ROOT/lib we have only one directory, right? Correct. That is what I achieved with the hardlinks, and will try to achieve shortly without them. > Surely, building for a distro can build in the right path. Not really. It would disrupt the running multiuser system. But it can probably use -rpath to stick paths in that don't correspond to the "staging" area. > Where did /tmp/cm3 come from? The distribution builds in /tmp. You don't have to be root or disrupt the running machine to build a distribution. There a question maybe of if the resulting files should be owned by root? > Elegance is also a concern. Agreed. Copying files in the build isn't elegant. The result is elegant imho. Hardlinks aren't elegant? I don't know. Anyway, ok, I'll just put the files in lib and no hardlinks, I'll try that. > Now, keep in mind, that unshipped binaries sometimes people like to work > I don't know understand what you are trying to say here. Let me think about unshipped binaries later.. One thing is that $origin doesn't work with unshipped binaries. By default we put in both $origin and the full path you like. But imho distributions should just have $origin. Or if user can't chose install location, maybe just the full path. The big question is if user can chose where to install. On birch I use $HOME/cm3. Seems kind of important/useful? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:02:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:02:56 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: Yes, now I remember. We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core. This implies the need for compilations upstream of m3core to function with both old and new versions. So, my question now is why did you introduce a dependency from the new cm3 to the new m3core? That should probably be avoided. On 2 Jul 2009, at 15:23, Jay wrote: > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:03:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:03:16 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> Message-ID: Ok, so I think a very important question is: >>> Should users have a choice of where to install? >>> What are the reasonable ramifications of someone who makes a non-default choice? /Personally/ I want the choice, esp. if I don't have root access!, and I don't want to set LD_LIBRARY_PATH. I want my choice and no negative consequences, and $origin basically gives me that. Except NetBSD prior to 5.0. 5.0 already released. And I guess Solaris prior to 2.7 or such. We do agree on a change vs. previous releases, at least. And it overlaps with what I did already. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 15:59:25 -0400 I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:05:25 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:05:25 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > why did you introduce a dependency to the new m3core I had removed link because it wasn't used, and/or didn't introduce it the first builds of e.g. AMD64_LINUX. Link naturally goes in m3core/src/unix. However implementing it locally in cm3 is reasonable. I should have tried harder on a clean local unshared solution. Not every .c file needs m3unix.h, though I am comforted by using it, that I have things all setup well and portably. Waitpid changes similar, you'll recall. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 16:02:56 -0400 Yes, now I remember. We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core. This implies the need for compilations upstream of m3core to function with both old and new versions. So, my question now is why did you introduce a dependency from the new cm3 to the new m3core? That should probably be avoided. On 2 Jul 2009, at 15:23, Jay wrote: >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:08:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:08:26 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: On 2 Jul 2009, at 15:30, Jay wrote: > Btw, I must say, that Modula-3 often bucks the trend, often with > reason and benefit. > However the "trend" has a lot of people behind it, using it, fixing > it, making sure it works. > The "trend", the popular practice, would include put the files in / > usr/local/cm3/lib and not pkg. I am fine with this. > Or, well, pkg could be an unused copy, but that's fairly pointless > and wasteful. I don't know what the reasons were for putting them in the pkg directories in the first place. > My use of hardlinks is not exactly "trendy". > But I was kinda sorta not breaking the "pkg philosophy". Does anyone recall if there was any real "philosophy" here? > It's like the putting an extra unused copy in pkg, but without much > space wastage (just directory entries) > > At least then the whole symlink/root thing can go away at least. > Though just using a relative path to get the source file or copying > and commiting a smaller piece of it, would be ok..if someone wants > hardlink primitive in cm3 for some reason still. I oppose hard links in general. > The runpath won't be huge then also, no matter how all the other > debating goes. > > > I need some time to settle down and think about it and /try it out/ > but at the moment I'm tempted by the ditching of pkg for .so files > and just them in lib. It will require probably new builder and > config file changes. RIght. > Really the current hardlink solution is extremely close to this, but > again, also not "trendy". > .a/.sa files would remain where they are, in pkg, though, of course, > there is "very trendy" precedent against that too. I suspect that the "pkg" philosophy dates from before .so shared libraries were even supported on most targets (yes, I can remember that long ago). > And then, er...what is left in pkg? Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). > > - Jay > > From: jay.krell at cornell.edu > To: jay.krell at cornell.edu; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 19:23:55 +0000 > Subject: Re: [M3devel] ROOT > > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:17:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:17:54 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> Message-ID: <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> On 2 Jul 2009, at 16:03, Jay wrote: > Ok, so I think a very important question is: > > >>> Should users have a choice of where to install? Yes! > >>> What are the reasonable ramifications of someone who makes a > non-default choice? > > /Personally/ I want the choice, esp. if I don't have root access!, > and I don't want to set LD_LIBRARY_PATH. > I want my choice and no negative consequences, and $origin basically > gives me that. > Except NetBSD prior to 5.0. 5.0 already released. > And I guess Solaris prior to 2.7 or such. > > > We do agree on a change vs. previous releases, at least. > And it overlaps with what I did already. I think so. (I just didn't like the link stuff and I still don't understand what ROOT is there for). > > > - Jay > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 15:59:25 -0400 > > I agree, LD_LIBRARY_PATH should only be used by power-users in a > pinch during development. > > On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:19:41 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:19:41 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > And then, er...what is left in pkg? Sorry, that was an unfinished thought. Various other things left, none of them will move. You might argue to move .sa files, but doesn't really matter, leave it alone, unless it is super duper convenient to move them along with the .so. It might be, because of how build_standalone works, or maybe only out of laziness. Except .so.5 along with .so. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 2 Jul 2009 16:08:26 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT On 2 Jul 2009, at 15:30, Jay wrote: Btw, I must say, that Modula-3 often bucks the trend, often with reason and benefit. However the "trend" has a lot of people behind it, using it, fixing it, making sure it works. The "trend", the popular practice, would include put the files in /usr/local/cm3/lib and not pkg. I am fine with this. Or, well, pkg could be an unused copy, but that's fairly pointless and wasteful. I don't know what the reasons were for putting them in the pkg directories in the first place. My use of hardlinks is not exactly "trendy". But I was kinda sorta not breaking the "pkg philosophy". Does anyone recall if there was any real "philosophy" here? It's like the putting an extra unused copy in pkg, but without much space wastage (just directory entries) At least then the whole symlink/root thing can go away at least. Though just using a relative path to get the source file or copying and commiting a smaller piece of it, would be ok..if someone wants hardlink primitive in cm3 for some reason still. I oppose hard links in general. The runpath won't be huge then also, no matter how all the other debating goes. I need some time to settle down and think about it and /try it out/ but at the moment I'm tempted by the ditching of pkg for .so files and just them in lib. It will require probably new builder and config file changes. RIght. Really the current hardlink solution is extremely close to this, but again, also not "trendy". .a/.sa files would remain where they are, in pkg, though, of course, there is "very trendy" precedent against that too. I suspect that the "pkg" philosophy dates from before .so shared libraries were even supported on most targets (yes, I can remember that long ago). And then, er...what is left in pkg? Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). - Jay From: jay.krell at cornell.edu To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: Re: [M3devel] ROOT >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:23:35 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:23:35 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> Message-ID: (I just didn't like the link stuff and I still don't understand what ROOT is there for). The point was to add Unix.link where it belongs, m3core, and use it from where can't depend on new m3core. And maybe go overboard in sharing the source, to a trivial one line function (less trivial on Win32, in order to support pre-Win2000 OS). The point was to put the files in lib and also leave them in pkg, without wasting space. The decision now, which I still have to try, is to stop putting the files in pkg, so then no hardlink needed. $origin vs. full paths is still debatable and I still convinced $origin is the way to go. I'm also inclined to put $origin and $origin/../lib in rpath, so backups can flatten the structure to just one directory: /backup/cm3 /backup/libm3core.so /backup/libm3.so in some /hypothetical future/ where cm3 is dynamically linked. As long there are no "duplicates" -- files in both bin and lib, the runpath remains fairly clear/unambiguous. And even then, the order is pretty clearly left to right.. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 16:17:54 -0400 On 2 Jul 2009, at 16:03, Jay wrote: Ok, so I think a very important question is: >>> Should users have a choice of where to install? Yes! >>> What are the reasonable ramifications of someone who makes a non-default choice? /Personally/ I want the choice, esp. if I don't have root access!, and I don't want to set LD_LIBRARY_PATH. I want my choice and no negative consequences, and $origin basically gives me that. Except NetBSD prior to 5.0. 5.0 already released. And I guess Solaris prior to 2.7 or such. We do agree on a change vs. previous releases, at least. And it overlaps with what I did already. I think so. (I just didn't like the link stuff and I still don't understand what ROOT is there for). - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 15:59:25 -0400 I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:24:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:24:08 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> On 2 Jul 2009, at 15:47, Jay wrote: > I half agree. ;-) > It'll be a few hours/days, maybe a week, but I'll take a stab at > only putting the files in lib. > I don't know if it'll be easy or not but I'll try. > Therefore no hardlinks. Cool! > But still $origin. I think so, but still not sure. > Unless maybe there is consensus that install must be /usr/local/ > cm3, unless you build/link yourself, then you can chose. My inclination is that a binary install (no build/link) is OK to be hardwired, but if $origin gives flexibility in that then perhaps worth supporting. But surely, for binary installs we will be using package managers to install to standard places so no need to adjust the paths? > And the distribution building will have to be sure to...um...? Be > done as root and impact the running system??? No.. > Well, distribution building can make it work somehow, by using - > rpath /usr/local/cm3/lib, even if ld is pointed at /tmp/cm3/lib/ > libfoo.so. I can look into that, if there is actually firm consensus > against $origin and for full paths, and for taking away user choice > of install location...but...but....what about non-admin installs? > They have to rebuild? As a non-admin installer on cm3, I can > probably live with that, but not sure about others..seems not great. > Another option is to link upon install, or "fixup" the paths on > systems that can do that without relinking. > Again I come back to favoring origin pretty strongly. OK, now I think I understand where you are coming from. You want binary installs (no build/link) for non-admin users to non-standard places. Seems like a desirable thing in theory. > Hard links seem perfectly migratable..they tar and untar at least.. > I get it probably though -- what flags to use to cp? There are too > many options, it confuses me. > I know hard links can't cross file systems, but often people only > hardlink "nearby" files that are the same file system anyway. > Hardlinks don't survive on Windows FAT filesystem, probably nobody > cares. They work fine on NTFS. > Some copy utilities might break them though, yeah, that happens. I generally avoid them because of the swamp you just described. > Full paths not using $origin aren't migratable. Right. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcolebur at scires.com > Date: Thu, 2 Jul 2009 15:37:45 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > I think best would be for Jay to reprise his thinking on why all of > this was needed. In general, I oppose hard links on the grounds > that they are not trivially migrateable. Better to have relative > symbolic links. If we can avoid the need for $origin by installing > libraries in a fixed INSTALL_ROOT/lib directory (rather than the > current symbolic links approach) then I prefer that. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 14:31, Randy Coleburn wrote: > > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:24:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:24:38 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > I oppose hard links in general. Why? This is hypothetical/just-curious now, because we have agreed to take away the need I had for them. But then when I think I want them tomorrow again, what is the reason not? :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:25:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:25:03 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: <6FB1A21F-E26D-435D-AEE2-1C2337E92C09@cs.purdue.edu> On 2 Jul 2009, at 16:19, Jay wrote: > > And then, er...what is left in pkg? > > > Sorry, that was an unfinished thought. > Various other things left, none of them will move. > You might argue to move .sa files, but doesn't really matter, leave > it alone, unless it is super duper convenient to move them along > with the .so. It might be, because of how build_standalone works, or > maybe only out of laziness. > Except .so.5 along with .so. RIght. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 2 Jul 2009 16:08:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > On 2 Jul 2009, at 15:30, Jay wrote: > > Btw, I must say, that Modula-3 often bucks the trend, often with > reason and benefit. > However the "trend" has a lot of people behind it, using it, fixing > it, making sure it works. > The "trend", the popular practice, would include put the files in / > usr/local/cm3/lib and not pkg. > > I am fine with this. > > Or, well, pkg could be an unused copy, but that's fairly pointless > and wasteful. > > I don't know what the reasons were for putting them in the pkg > directories in the first place. > > My use of hardlinks is not exactly "trendy". > But I was kinda sorta not breaking the "pkg philosophy". > > Does anyone recall if there was any real "philosophy" here? > > It's like the putting an extra unused copy in pkg, but without much > space wastage (just directory entries) > > At least then the whole symlink/root thing can go away at least. > Though just using a relative path to get the source file or copying > and commiting a smaller piece of it, would be ok..if someone wants > hardlink primitive in cm3 for some reason still. > > I oppose hard links in general. > > The runpath won't be huge then also, no matter how all the other > debating goes. > > > I need some time to settle down and think about it and /try it out/ > but at the moment I'm tempted by the ditching of pkg for .so files > and just them in lib. It will require probably new builder and > config file changes. > > RIght. > > Really the current hardlink solution is extremely close to this, but > again, also not "trendy". > .a/.sa files would remain where they are, in pkg, though, of course, > there is "very trendy" precedent against that too. > > I suspect that the "pkg" philosophy dates from before .so shared > libraries were even supported on most targets (yes, I can remember > that long ago). > > And then, er...what is left in pkg? > > Sources. For browsing by the various Modula-3 tools. Come to think > of it, that reminds me -- the package browsing tools (eg, m3browser) > rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, > this argues for only moving the .so files to INSTALL_ROOT/lib and > leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived > sources in the pkg/TARGET directories where they currently reside). > > > - Jay > > From: jay.krell at cornell.edu > To: jay.krell at cornell.edu; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 19:23:55 +0000 > Subject: Re: [M3devel] ROOT > > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:26:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:26:38 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> Message-ID: <51053E7F-533F-4951-9E13-62122B2BB983@cs.purdue.edu> I think we are converging on a reasonable compromise (as noted in my other responses). On 2 Jul 2009, at 15:59, Jay wrote: > > copy and commit the source to cm3 is viable > > I don't know what this sentence means. > > I don't have to be copying files around in the build order for cm3 > to create hard links. > I can just copy on my machine and commit to cvs a little bit of code > to do it. > That isn't nearly as hacky. > > > heck, use a relative instead of absolute from ROOT > > ditto > > > $origin it turns out is very portable. > Every system we support except NetBSD 4.0 seems to have it, and > even some we don't currently support. > And NetBSD 5.0, which already released, has it. > And MacOSX is plenty close enough. It is a matter of relative to > the executable or the reference, and which OS version you support. I > believe newer versions relaly do have $origin by another name, but > 10.4 has relative to the executable, which is good enough to me. > > If you don't use $origin, then people either must install to the one > true place, or they must use LD_LIBRARY_PATH, or they must rebuild/ > relink/fixup themselves. > > LD_LIBRARY_PATH is widely panned. > Having to rebuild seems onerous for most people. > Having a choice of where to install? Important? > > > > Right. rpaths in the executable should do the trick. > > Just in the executable? Shouldn't they somewhat be in the shared > libraries? > If foo uses libm3 and libm3 uses m3core and foo doesn't use m3core, > arguably foo shouldn't mention m3core, only libm3 should. > > > > Ideally we use the same approach for *all* platforms. So, what > do all platforms have in common. > > $origin comes extremely close to that, and provides the benefit that > user can specify where to install. > > > > and if there is need for override use $LD_LIBRARY_PATH. > > But again (I know, I repeated myself, so you did, now I am), this > forces any install to non-default location to use LD_LIBRARY_PATH. > It is an option. But $origin is also /very/ portable... > > >> But if everything goes in INSTALL_ROOT/lib we have only one > directory, right? > > Correct. That is what I achieved with the hardlinks, and will try to > achieve shortly without them. > > > Surely, building for a distro can build in the right path. > > Not really. It would disrupt the running multiuser system. > But it can probably use -rpath to stick paths in that don't > correspond to the "staging" area. > > > > Where did /tmp/cm3 come from? > > The distribution builds in /tmp. You don't have to be root or > disrupt the running machine to build a distribution. > There a question maybe of if the resulting files should be owned by > root? > > > > Elegance is also a concern. > > Agreed. Copying files in the build isn't elegant. The result is > elegant imho. > Hardlinks aren't elegant? I don't know. > Anyway, ok, I'll just put the files in lib and no hardlinks, I'll > try that. > > Now, keep in mind, that unshipped binaries sometimes people like > to work > > I don't know understand what you are trying to say here. > > Let me think about unshipped binaries later.. > One thing is that $origin doesn't work with unshipped binaries. > By default we put in both $origin and the full path you like. > But imho distributions should just have $origin. > Or if user can't chose install location, maybe just the full path. > The big question is if user can chose where to install. > On birch I use $HOME/cm3. > Seems kind of important/useful? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:30:47 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:30:47 +0000 Subject: [M3devel] ROOT In-Reply-To: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: > But surely, for binary installs we will be using package managers to install to standard places so no need to adjust the paths? Yes and no. In fact, yes, I made some .deb files, and they have no choice of where to install. They have no "install code", beyond dpkg. But .deb files often do have install scripts in them. It's not a hard requirement to avoid. And the normal workflow with apt-get install doesn't give you a choice of install location either. Historically we don't have little/no use of package manages. Therefore open the other can of worms of what a binary install should look like... (Echoing Olaf here) There are way too many install formats, while it is nice for us to support some of them, it behooves us to have our own low end portable form, and we have some say in the feature set of it, such as if you can chose the install location. (We could also adopt one of the native ones as our portable one, if it is in fact portable; .deb it turns out is actually promising in this regard, it takes like two lines of .sh to install a .deb on pretty much any system, assuming the contents are for it; they are just a .tar.gz bundled with very little else in an ar file.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 19:34:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 10:34:55 -0700 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> How about we put .so files only in lib and not in pkg? Or symlink from pkg to lib instead of how it used to be the other way around? Those would also fix all this. - Jay (phone) On Jul 2, 2009, at 9:21 AM, Jay wrote: > > Are you up to date in m3-libs/m3core? > Lots of builds have succeeded with this.. > It isn't great, but that requirement to build from previous 5.4 > release.. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 2 Jul 2009 11:54:51 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ROOT >> >> If I define ROOT then I get the following error. I think this all >> needs reverting! >> >> --- building in SOLgnu --- >> >> ignoring ../src/m3overrides >> >> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: >> quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ >> Common/UnixLink.c" to "./UnixLink.c": errno=2 >> >> --procedure-- -line- -file--- >> cp_if -- >> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >> m3makefile >> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >> >> Fatal Error: package build failed >> n >> >> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as >> it sets that structure in stone. >> >> From jay.krell at cornell.edu Thu Jul 2 22:35:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:35:20 +0000 Subject: [M3devel] ROOT In-Reply-To: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: > You want binary installs (no build/link) for non-admin users to non-standard places Right, and without having to set LD_LIBRARY_PATH (except on NetBSD 4.0 :) ) "What is the cost of a non-default install location?" - Jay From: hosking at cs.purdue.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:39:13 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:39:13 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: In the meantime btw, I assert things are broken. Consider putting it all back as it was. Tonight I can try using a relative path instead of ROOT, as a baby step. Or I can commit the code so that build doesn't copy it. Or we can have cm3 depend on m3core and leave "release" broken for a bit. As I said, I wouldn't mind relaxing that requirement (I suspect Olaf disagrees strongly though.) Or you can finish the reversion by lookin for "hardlink" in the config files and changing it to just "link". That might work. Might. Really, more so, look for the uses of $origin and remove them too. I really need to run catch a plain and spend time with family though. Later, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 23:02:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 14:02:48 -0700 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: I can put if back tonight and then remove 'root' and then hardlinks will remain temporarily. - Jay (phone) On Jul 2, 2009, at 1:39 PM, Jay wrote: > In the meantime btw, I assert things are broken. > > Consider putting it all back as it was. > > Tonight I can try using a relative path instead of ROOT, as a baby > step. > Or I can commit the code so that build doesn't copy it. > > Or we can have cm3 depend on m3core and leave "release" broken for a > bit. > As I said, I wouldn't mind relaxing that requirement (I suspect Olaf > disagrees strongly though.) > > Or you can finish the reversion by lookin for "hardlink" in the > config files and changing it to just "link". > That might work. Might. > Really, more so, look for the uses of $origin and remove them too. > > > I really need to run catch a plain and spend time with family though. > > > Later, > - Jay From jay.krell at cornell.edu Thu Jul 2 23:04:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 14:04:40 -0700 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: (and keep it compatible with old cm3) - Jay (phone) On Jul 2, 2009, at 2:02 PM, jayk123 at hotmail.com wrote: > I can put if back tonight and then remove 'root' and then hardlinks > will remain temporarily. > > - Jay (phone) > > On Jul 2, 2009, at 1:39 PM, Jay wrote: > >> In the meantime btw, I assert things are broken. >> >> Consider putting it all back as it was. >> >> Tonight I can try using a relative path instead of ROOT, as a baby >> step. >> Or I can commit the code so that build doesn't copy it. >> >> Or we can have cm3 depend on m3core and leave "release" broken for >> a bit. >> As I said, I wouldn't mind relaxing that requirement (I suspect >> Olaf disagrees strongly though.) >> >> Or you can finish the reversion by lookin for "hardlink" in the >> config files and changing it to just "link". >> That might work. Might. >> Really, more so, look for the uses of $origin and remove them too. >> >> >> I really need to run catch a plain and spend time with family though. >> >> >> Later, >> - Jay From rcolebur at scires.com Thu Jul 2 23:54:51 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 17:54:51 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: <4A4CF46A.1E75.00D7.1@scires.com> Also, let us not forget about CM3IDE (formerly Reactor). It can browse multiple repositories, some marked public and some marked private. We don't want to introduce changes in the way stuff is shipped that would break CM3IDE or M3BROWSER. I think the browsing capabilities in CM3IDE are an outgrowth of the old m3browser and expand upon it to show dependencies, lists of interfaces/implementions imported/exported, etc. etc. CM3IDE also relies on knowledge of the cm3 file tree to locate stuff and to create new packages, etc. If we muck around too much with all of this, we risk breaking CM3IDE or at least having to adapt it to whatever new structure/rules are in place. Regards, Randy Coleburn >>> Tony Hosking 7/2/2009 4:08 PM >>> Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jul 3 00:19:15 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 15:19:15 -0700 Subject: [M3devel] ROOT In-Reply-To: <4A4CF46A.1E75.00D7.1@scires.com> References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> <4A4CF46A.1E75.00D7.1@scires.com> Message-ID: <56A22159-9AB8-4A47-B5BF-3812A45051B4@hotmail.com> Ok. I doubt IDE cares about this and we can make symlinks on most platforms. We will not move .m3web .m3exports .m3x etc. - Jay (phone) On Jul 2, 2009, at 2:54 PM, "Randy Coleburn" wrote: > Also, let us not forget about CM3IDE (formerly Reactor). It can > browse multiple repositories, some marked public and some marked > private. We don't want to introduce changes in the way stuff is > shipped that would break CM3IDE or M3BROWSER. I think the browsing > capabilities in CM3IDE are an outgrowth of the old m3browser and > expand upon it to show dependencies, lists of interfaces/ > implementions imported/exported, etc. etc. CM3IDE also relies on > knowledge of the cm3 file tree to locate stuff and to create new > packages, etc. If we muck around too much with all of this, we risk > breaking CM3IDE or at least having to adapt it to whatever new > structure/rules are in place. > Regards, > Randy Coleburn > > >>> Tony Hosking 7/2/2009 4:08 PM >>> > Sources. For browsing by the various Modula-3 tools. Come to think > of it, that reminds me -- the package browsing tools (eg, m3browser) > rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, > this argues for only moving the .so files to INSTALL_ROOT/lib and > leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived > sources in the pkg/TARGET directories where they currently reside). From rcolebur at scires.com Fri Jul 3 01:14:58 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 19:14:58 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: <4A4D0732.1E75.00D7.1@scires.com> I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release. 1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms. 2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. 3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure: +---foo | +---src | +---NT386 | +---HPPA | \---(...) 4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) 5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure: CM3 +---bin +---doc | +---help | +---pics | +---reference | +---src_reports | \---tutorial +---examples +---lib +---pkg | +---bitvector | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---cm3ide | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---(...) | | +---src | | +---NT386 | | +---HPPA | | \---(...) 6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly. 7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken. 8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed. Hope this info is helpful. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jul 3 03:50:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:50:55 -0700 Subject: [M3devel] ROOT In-Reply-To: <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> Message-ID: <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> In particular I would argue that the directory layout should be made right at link time, into an alternate root. That alternate root possibly be prepopulated with links to or copies of the current good shared repository. Or the compiler should have notion of multiple roots to probe. However running the stuff implies hardlinks that are broken upon write. This scheme works better if source/interfaces are not needed in repository, just to cut down on the size. Are shipped source/interfaces used by compiler, or just the .m3exports/.m3x files? Anyway this is all thinking for a future release, not this year. 'ship' becomes just recursive copy or move.or change roots, plus maybe shipping source/interfaces too, kind of a wart. - Jay (phone) On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > The system used/uses symlinks under the covers. I don't think cm3 > historically supported shared libs on hpux probably because the > bundled compiler does not. Granted my exposure to hpux is only in > recent times. 'standalone' as you define is useful but I think that > reason isn't applicable to anything 'within cm3 itself'. Maybe more > to say later. In particular I think this design we have is flawed. > It's goals are good but can be better achieved slightly differently. > In particular the unshipped and shipped directory layout should be > 'the same' but just differently rooted. Not in this release though. > That let's $origin work better, among other advantages. Related and > possibly solved same IMHO we don't adequately separate source and > output - it should separate across multiple packages not just one at > a time. But again, not on this release. > > - Jay (phone) > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" > wrote: > >> I thought it might be helpful to highlight some of what I've always >> understood as the design for the CM3 package system. So, I pulled >> out my old documentation from Critical Mass as reference. >> >> I offer the following information to see if this discussion thread >> concurs and/or wants to make any changes going forward, esp. as we >> prepare for a new CM3 release. >> >> 1. CM3 takes care to separate source and derived files because >> doing so (a) isolates source files for backup, revision control, >> and searching; and (b) enables sharing the same source tree across >> operating systems and architectures, without confusing object files >> from different platforms. >> >> 2. Each package resides in a directory, with sources in a source >> subdirectory ("src"), and generated files in a derived subdirectory >> named to denote the platform on which the sources were built, e.g., >> "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. >> >> 3. Each developer can have multiple private packages, each stored >> wherever desired in the filesystem. A private package named "foo" >> would have the following filesystem structure: >> +---foo >> | +---src >> | +---NT386 >> | +---HPPA >> | \---(...) >> >> 4. For each CM3 installation, there is one public package >> repository that is available to all developers. When you ship a >> [private] package, you make that package available to other >> packages (and developers) via this public package repository. The >> idea is that as a developer you would test your package in your >> private repository before shipping it to the public repository. >> (Sometimes m3overrides were needed when testing several related >> private packages before shipping them.) >> >> 5. A typical CM3 installation is rooted at a given point in the >> file system and contains the following folder structure: >> CM3 >> +---bin >> +---doc >> | +---help >> | +---pics >> | +---reference >> | +---src_reports >> | \---tutorial >> +---examples >> +---lib >> +---pkg >> | +---bitvector >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> | +---cm3ide >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> | +---(...) >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> >> 6. In the past, the environment variable INSTALL_ROOT pointed to >> the root of the CM3 tree in the file system. I think this variable >> is ambiguously named and that we should change it to >> CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 >> installations (perhaps for different releases), one would simply >> need to change the CM3_INSTALL_ROOT variable to point to the >> desired installation for use at any particular point in time. For >> this to work, all other variables cue off of CM3_INSTALL_ROOT. I >> know that for the old cm3.cfg file, this was indeed the behavior. >> Then, if someone had a special situation, they could override the >> "cueing" behavior for any particular variable simply by changing >> its definition on the fly. >> >> 7. Now, I also understand some (but not all) of what Jay is saying >> about the library paths. Back in the old cm3 v4.1 days, I had both >> HPPA and NT386 derived files for the same set of sources. For >> Windows, the shipped exe and dll files went into the public >> repository and you needed to have the CM3/bin folder on your path. >> For private exe and dlls, you typically just ran them out of the >> private package's derived NT386 folder. On HPPA, there were some >> places in the file system that contained static libraries and >> shared libraries, plus then you had the libraries built using CM3. >> Again, the CM3 libraries went to the public repository and there >> were environment variables to facilitate finding the rest, >> including LD_LIBRARY_PATH. Now, from what Jay is saying, the >> variety of operating environments seems to cloud up all this. I >> know I'm a bit rusty wrt all the various unix variants out there, >> but I recall that v4.1 worked out-of-the-box for both NT386 and >> HPPA with respect to all this library path stuff and I didn't have >> to make any symbolic links nor any hard links to make it work. >> IMO, links are bad and too easily broken. >> >> 8. As for "build_standalone", I know there are various build/ >> bootstrap reasons why some parts of CM3 had to be built this way. >> But, for me, I've often used this feature for utility-type programs >> to make it easier to distribute them. I can simply distribute the >> one executable file without having to worry that the target system >> might not have the right DLLs or the right shared libraries in the >> right locations. For production code, I've always built an >> installation program or an installation script that installed all >> my executables and shared libraries in a folder structure rooted at >> a particular point chosen by the end user. Then, my programs >> always launched and used relative paths from the install location >> to find everything they needed. >> >> Hope this info is helpful. >> >> Regards, >> Randy Coleburn >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 03:57:38 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:57:38 -0700 Subject: [M3devel] ROOT In-Reply-To: <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> Message-ID: <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> Ps this would also obsolete m3overrides, providing similar but better functionality, no need to encode the source structure in all those little extra files. - Jay (phone) On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > In particular I would argue that the directory layout should be made > right at link time, into an alternate root. That alternate root > possibly be prepopulated with links to or copies of the current good > shared repository. Or the compiler should have notion of multiple > roots to probe. However running the stuff implies hardlinks that are > broken upon write. This scheme works better if source/interfaces are > not needed in repository, just to cut down on the size. Are shipped > source/interfaces used by compiler, or just the .m3exports/.m3x > files? Anyway this is all thinking for a future release, not this > year. 'ship' becomes just recursive copy or move.or change roots, > plus maybe shipping source/interfaces too, kind of a wart. > > - Jay (phone) > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > >> The system used/uses symlinks under the covers. I don't think cm3 >> historically supported shared libs on hpux probably because the >> bundled compiler does not. Granted my exposure to hpux is only in >> recent times. 'standalone' as you define is useful but I think that >> reason isn't applicable to anything 'within cm3 itself'. Maybe more >> to say later. In particular I think this design we have is flawed. >> It's goals are good but can be better achieved slightly >> differently. In particular the unshipped and shipped directory >> layout should be 'the same' but just differently rooted. Not in >> this release though. That let's $origin work better, among other >> advantages. Related and possibly solved same IMHO we don't >> adequately separate source and output - it should separate across >> multiple packages not just one at a time. But again, not on this >> release. >> >> - Jay (phone) >> >> On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" >> wrote: >> >>> I thought it might be helpful to highlight some of what I've >>> always understood as the design for the CM3 package system. So, I >>> pulled out my old documentation from Critical Mass as reference. >>> >>> I offer the following information to see if this discussion thread >>> concurs and/or wants to make any changes going forward, esp. as we >>> prepare for a new CM3 release. >>> >>> 1. CM3 takes care to separate source and derived files because >>> doing so (a) isolates source files for backup, revision control, >>> and searching; and (b) enables sharing the same source tree across >>> operating systems and architectures, without confusing object >>> files from different platforms. >>> >>> 2. Each package resides in a directory, with sources in a source >>> subdirectory ("src"), and generated files in a derived >>> subdirectory named to denote the platform on which the sources >>> were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. >>> >>> 3. Each developer can have multiple private packages, each stored >>> wherever desired in the filesystem. A private package named "foo" >>> would have the following filesystem structure: >>> +---foo >>> | +---src >>> | +---NT386 >>> | +---HPPA >>> | \---(...) >>> >>> 4. For each CM3 installation, there is one public package >>> repository that is available to all developers. When you ship a >>> [private] package, you make that package available to other >>> packages (and developers) via this public package repository. The >>> idea is that as a developer you would test your package in your >>> private repository before shipping it to the public repository. >>> (Sometimes m3overrides were needed when testing several related >>> private packages before shipping them.) >>> >>> 5. A typical CM3 installation is rooted at a given point in the >>> file system and contains the following folder structure: >>> CM3 >>> +---bin >>> +---doc >>> | +---help >>> | +---pics >>> | +---reference >>> | +---src_reports >>> | \---tutorial >>> +---examples >>> +---lib >>> +---pkg >>> | +---bitvector >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> | +---cm3ide >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> | +---(...) >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> >>> 6. In the past, the environment variable INSTALL_ROOT pointed to >>> the root of the CM3 tree in the file system. I think this >>> variable is ambiguously named and that we should change it to >>> CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 >>> installations (perhaps for different releases), one would simply >>> need to change the CM3_INSTALL_ROOT variable to point to the >>> desired installation for use at any particular point in time. For >>> this to work, all other variables cue off of CM3_INSTALL_ROOT. I >>> know that for the old cm3.cfg file, this was indeed the behavior. >>> Then, if someone had a special situation, they could override the >>> "cueing" behavior for any particular variable simply by changing >>> its definition on the fly. >>> >>> 7. Now, I also understand some (but not all) of what Jay is >>> saying about the library paths. Back in the old cm3 v4.1 days, I >>> had both HPPA and NT386 derived files for the same set of >>> sources. For Windows, the shipped exe and dll files went into the >>> public repository and you needed to have the CM3/bin folder on >>> your path. For private exe and dlls, you typically just ran them >>> out of the private package's derived NT386 folder. On HPPA, there >>> were some places in the file system that contained static >>> libraries and shared libraries, plus then you had the libraries >>> built using CM3. Again, the CM3 libraries went to the public >>> repository and there were environment variables to facilitate >>> finding the rest, including LD_LIBRARY_PATH. Now, from what Jay >>> is saying, the variety of operating environments seems to cloud up >>> all this. I know I'm a bit rusty wrt all the various unix >>> variants out there, but I recall that v4.1 worked out-of-the-box >>> for both NT386 and HPPA with respect to all this library path >>> stuff and I didn't have to make any symbolic links nor any hard >>> links to make it work. IMO, links are bad and too easily broken. >>> >>> 8. As for "build_standalone", I know there are various build/ >>> bootstrap reasons why some parts of CM3 had to be built this way. >>> But, for me, I've often used this feature for utility-type >>> programs to make it easier to distribute them. I can simply >>> distribute the one executable file without having to worry that >>> the target system might not have the right DLLs or the right >>> shared libraries in the right locations. For production code, >>> I've always built an installation program or an installation >>> script that installed all my executables and shared libraries in a >>> folder structure rooted at a particular point chosen by the end >>> user. Then, my programs always launched and used relative paths >>> from the install location to find everything they needed. >>> >>> Hope this info is helpful. >>> >>> Regards, >>> Randy Coleburn >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 03:36:16 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:36:16 -0700 Subject: [M3devel] ROOT In-Reply-To: <4A4D0732.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> Message-ID: <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release. - Jay (phone) On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > I thought it might be helpful to highlight some of what I've always > understood as the design for the CM3 package system. So, I pulled > out my old documentation from Critical Mass as reference. > > I offer the following information to see if this discussion thread > concurs and/or wants to make any changes going forward, esp. as we > prepare for a new CM3 release. > > 1. CM3 takes care to separate source and derived files because > doing so (a) isolates source files for backup, revision control, and > searching; and (b) enables sharing the same source tree across > operating systems and architectures, without confusing object files > from different platforms. > > 2. Each package resides in a directory, with sources in a source > subdirectory ("src"), and generated files in a derived subdirectory > named to denote the platform on which the sources were built, e.g., > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > 3. Each developer can have multiple private packages, each stored > wherever desired in the filesystem. A private package named "foo" > would have the following filesystem structure: > +---foo > | +---src > | +---NT386 > | +---HPPA > | \---(...) > > 4. For each CM3 installation, there is one public package > repository that is available to all developers. When you ship a > [private] package, you make that package available to other packages > (and developers) via this public package repository. The idea is > that as a developer you would test your package in your private > repository before shipping it to the public repository. (Sometimes > m3overrides were needed when testing several related private > packages before shipping them.) > > 5. A typical CM3 installation is rooted at a given point in the > file system and contains the following folder structure: > CM3 > +---bin > +---doc > | +---help > | +---pics > | +---reference > | +---src_reports > | \---tutorial > +---examples > +---lib > +---pkg > | +---bitvector > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---cm3ide > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---(...) > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > > 6. In the past, the environment variable INSTALL_ROOT pointed to > the root of the CM3 tree in the file system. I think this variable > is ambiguously named and that we should change it to > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > installations (perhaps for different releases), one would simply > need to change the CM3_INSTALL_ROOT variable to point to the desired > installation for use at any particular point in time. For this to > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > for the old cm3.cfg file, this was indeed the behavior. Then, if > someone had a special situation, they could override the "cueing" > behavior for any particular variable simply by changing its > definition on the fly. > > 7. Now, I also understand some (but not all) of what Jay is saying > about the library paths. Back in the old cm3 v4.1 days, I had both > HPPA and NT386 derived files for the same set of sources. For > Windows, the shipped exe and dll files went into the public > repository and you needed to have the CM3/bin folder on your path. > For private exe and dlls, you typically just ran them out of the > private package's derived NT386 folder. On HPPA, there were some > places in the file system that contained static libraries and shared > libraries, plus then you had the libraries built using CM3. Again, > the CM3 libraries went to the public repository and there were > environment variables to facilitate finding the rest, including > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > operating environments seems to cloud up all this. I know I'm a bit > rusty wrt all the various unix variants out there, but I recall that > v4.1 worked out-of-the-box for both NT386 and HPPA with respect to > all this library path stuff and I didn't have to make any symbolic > links nor any hard links to make it work. IMO, links are bad and > too easily broken. > > 8. As for "build_standalone", I know there are various build/ > bootstrap reasons why some parts of CM3 had to be built this way. > But, for me, I've often used this feature for utility-type programs > to make it easier to distribute them. I can simply distribute the > one executable file without having to worry that the target system > might not have the right DLLs or the right shared libraries in the > right locations. For production code, I've always built an > installation program or an installation script that installed all my > executables and shared libraries in a folder structure rooted at a > particular point chosen by the end user. Then, my programs always > launched and used relative paths from the install location to find > everything they needed. > > Hope this info is helpful. > > Regards, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Fri Jul 3 08:40:27 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 3 Jul 2009 02:40:27 -0400 Subject: [M3devel] ROOT In-Reply-To: <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> Message-ID: <4A4D6F9A.1E75.00D7.1@scires.com> Jay: Not sure I fully appreciate/understand your last 3 posts below. I'd also like to hear what Tony and Olaf think about all this. Regards, Randy >>> 7/2/2009 9:57 PM >>> Ps this would also obsolete m3overrides, providing similar but better functionality, no need to encode the source structure in all those little extra files. - Jay (phone) On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: In particular I would argue that the directory layout should be made right at link time, into an alternate root. That alternate root possibly be prepopulated with links to or copies of the current good shared repository. Or the compiler should have notion of multiple roots to probe. However running the stuff implies hardlinks that are broken upon write. This scheme works better if source/interfaces are not needed in repository, just to cut down on the size. Are shipped source/interfaces used by compiler, or just the .m3exports/.m3x files? Anyway this is all thinking for a future release, not this year. 'ship' becomes just recursive copy or move.or change roots, plus maybe shipping source/interfaces too, kind of a wart. - Jay (phone) On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release. - Jay (phone) On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release. 1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms. 2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. 3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure: +---foo | +---src | +---NT386 | +---HPPA | \---(...) 4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) 5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure: CM3 +---bin +---doc | +---help | +---pics | +---reference | +---src_reports | \---tutorial +---examples +---lib +---pkg | +---bitvector | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---cm3ide | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---(...) | | +---src | | +---NT386 | | +---HPPA | | \---(...) 6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly. 7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken. 8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed. Hope this info is helpful. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From rcolebur at scires.com Fri Jul 3 08:42:50 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 3 Jul 2009 02:42:50 -0400 Subject: [M3devel] reminder about email replies to this list Message-ID: <4A4D702A.1E75.00D7.1@scires.com> I notice that I am getting two and three email messages containing the same text. I suspect that folks are just choosing to "reply all". Please note that you should really just reply to m3devel. That way we don't get multiple copies. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Fri Jul 3 11:22:05 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 11:22:05 +0200 Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT In-Reply-To: <4A4D6F9A.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> <4A4D6F9A.1E75.00D7.1@scires.com> Message-ID: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> Quoting Randy Coleburn : > Jay: > > Not sure I fully appreciate/understand your last 3 posts below. > > I'd also like to hear what Tony and Olaf think about all this. I think Jay chiefly opts for a long unimplemented wish of mine: a hierarchy of repositories that is searched by the M3 builder. Imagine that you can have one global repository, which contains some standard and base packages and tools, and several project repositories, each of which is used by teams whose members all have private repositories for their own test and development purposes. A note on terminology: I don't really like to use the term `repository' here, as it is usually used in connection with version control systems. In ComPact, a tool developed and used years ago by Elego, we called these `repositories' which contained pre-built packages `package pools' or just `pools'. So I'll use that term instead of repository from now on. The CM3 builder needs to be extended to search a set of pools instead of just one (INSTALL_ROOT). This could be expressed by a CM3_POOL_PATH, similar to the Java class path: CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 To satisfy package imports, the builder would start searching in the first pool and continue until it has found an appropriate package. This way local or project changes could easily be tested and integrated before being `promoted' to a higher level. For backward compatibility reasons, there should be a default pool (/usr/local/cm3) which is used when nothing else is defined. Shipping of packages would by default use the first pool found in the CM3_POOL_PATH. The second extension needed would be the `promote' operation, which ships a package from one pool to another pool. Of course CM3 would need to make sure that all dependencies are correct and the shipped package does actually work within the new context (the destination pool's packages). If the package structure is the same in the workspace and in package pools, standard shipping and promoting operations would just be file copies (after appropriate correctness checks) as Jay says. Also, as Jay noticed, the `hack' of m3overrides wouldn't be necessary any more. I don't think this would be too difficult to implement. I just haven't found the time to do it yet ;-) Some further remarks to topics touched below: Shared libraries weren't in wide-spread use when the M3 package systme was designed. Only few of the DEC SRC targets actually contained support for them. IMO it's OK to ship them all to one directory, but to make things work for multi-architecture pools, we'd need to distinguish the library and binary paths there, too. So we'd have something like root/pkg/pkg-a/src /NT386 /I386_DARWIN /pkg-b/src /NT386 /I386_DARWIN /man /bin/NT386 /I386_DARWIN ... /lib/NT386 /I386_DARWIN ... Symbolic links were used for dynamic libraries by the related quake code as long as I remember. The variable ROOT is legacy, I think it was used for overrides even by DEC SRC. I've got no objection to rename it, but, as described above, we should rather make it vanish. Olaf > Regards, > Randy > >>>> 7/2/2009 9:57 PM >>> > > Ps this would also obsolete m3overrides, providing similar but > better functionality, no need to encode the source structure in all > those little extra files. > > - Jay (phone) > > On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > > > In particular I would argue that the directory layout should be made > right at link time, into an alternate root. That alternate root > possibly be prepopulated with links to or copies of the current good > shared repository. Or the compiler should have notion of multiple > roots to probe. However running the stuff implies hardlinks that are > broken upon write. This scheme works better if source/interfaces > are not needed in repository, just to cut down on the size. Are > shipped source/interfaces used by compiler, or just the > .m3exports/.m3x files? Anyway this is all thinking for a future > release, not this year. 'ship' becomes just recursive copy or > move.or change roots, plus maybe shipping source/interfaces too, > kind of a wart. > > - Jay (phone) > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > > > The system used/uses symlinks under the covers. I don't think cm3 > historically supported shared libs on hpux probably because the > bundled compiler does not. Granted my exposure to hpux is only in > recent times. 'standalone' as you define is useful but I think that > reason isn't applicable to anything 'within cm3 itself'. Maybe more > to say later. In particular I think this design we have is flawed. > It's goals are good but can be better achieved slightly differently. > In particular the unshipped and shipped directory layout should be > 'the same' but just differently rooted. Not in this release though. > That let's $origin work better, among other advantages. Related and > possibly solved same IMHO we don't adequately separate source and > output - it should separate across multiple packages not just one at > a time. But again, not on this release. > > - Jay (phone) > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > > > I thought it might be helpful to highlight some of what I've always > understood as the design for the CM3 package system. So, I pulled > out my old documentation from Critical Mass as reference. > > I offer the following information to see if this discussion thread > concurs and/or wants to make any changes going forward, esp. as we > prepare for a new CM3 release. > > 1. CM3 takes care to separate source and derived files because > doing so (a) isolates source files for backup, revision control, and > searching; and (b) enables sharing the same source tree across > operating systems and architectures, without confusing object files > from different platforms. > > 2. Each package resides in a directory, with sources in a source > subdirectory ("src"), and generated files in a derived subdirectory > named to denote the platform on which the sources were built, e.g., > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > 3. Each developer can have multiple private packages, each stored > wherever desired in the filesystem. A private package named "foo" > would have the following filesystem structure: > +---foo > | +---src > | +---NT386 > | +---HPPA > | \---(...) > > 4. For each CM3 installation, there is one public package > repository that is available to all developers. When you ship a > [private] package, you make that package available to other packages > (and developers) via this public package repository. The idea is > that as a developer you would test your package in your private > repository before shipping it to the public repository. (Sometimes > m3overrides were needed when testing several related private > packages before shipping them.) > > 5. A typical CM3 installation is rooted at a given point in the > file system and contains the following folder structure: > CM3 > +---bin > +---doc > | +---help > | +---pics > | +---reference > | +---src_reports > | \---tutorial > +---examples > +---lib > +---pkg > | +---bitvector > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---cm3ide > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---(...) > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > > 6. In the past, the environment variable INSTALL_ROOT pointed to > the root of the CM3 tree in the file system. I think this variable > is ambiguously named and that we should change it to > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > installations (perhaps for different releases), one would simply > need to change the CM3_INSTALL_ROOT variable to point to the desired > installation for use at any particular point in time. For this to > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > for the old cm3.cfg file, this was indeed the behavior. Then, if > someone had a special situation, they could override the "cueing" > behavior for any particular variable simply by changing its > definition on the fly. > > 7. Now, I also understand some (but not all) of what Jay is saying > about the library paths. Back in the old cm3 v4.1 days, I had both > HPPA and NT386 derived files for the same set of sources. For > Windows, the shipped exe and dll files went into the public > repository and you needed to have the CM3/bin folder on your path. > For private exe and dlls, you typically just ran them out of the > private package's derived NT386 folder. On HPPA, there were some > places in the file system that contained static libraries and shared > libraries, plus then you had the libraries built using CM3. Again, > the CM3 libraries went to the public repository and there were > environment variables to facilitate finding the rest, including > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > operating environments seems to cloud up all this. I know I'm a bit > rusty wrt all the various unix variants out there, but I recall > that v4.1 worked out-of-the-box for both NT386 and HPPA with > respect to all this library path stuff and I didn't have to make > any symbolic links nor any hard links to make it work. IMO, links > are bad and too easily broken. > > 8. As for "build_standalone", I know there are various > build/bootstrap reasons why some parts of CM3 had to be built this > way. But, for me, I've often used this feature for utility-type > programs to make it easier to distribute them. I can simply > distribute the one executable file without having to worry that the > target system might not have the right DLLs or the right shared > libraries in the right locations. For production code, I've always > built an installation program or an installation script that > installed all my executables and shared libraries in a folder > structure rooted at a particular point chosen by the end user. > Then, my programs always launched and used relative paths from the > install location to find everything they needed. > > Hope this info is helpful. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 3 13:25:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 11:25:28 +0000 Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT In-Reply-To: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> <4A4D6F9A.1E75.00D7.1@scires.com> <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> Message-ID: [didn't really finish editing this..ran out of energe..] Cool. > For backward compatibility reasons, there should be a default pool > (/usr/local/cm3) which is used when nothing else is defined. "I THINK:" (ie: I'm not sure, winging it..) The last pool searched would correspond to where the compiler is. The first one might be ROOT/pkg. I'd kind of like it to be outside ROOT entirely, but having it be one toplevel directory in ROOT is progress. ? An initial version that only supports two pools doesn't rqeuire another setting. ? You know, do-cm3-all realclean would be rm -rf firstpool and optionally "clone" or "populate" firstpool from secondpool. Clone/populate might be separate step, such as if I'm cleaning now, but not building till later. ? A system with multiple pools requires more thought than just two pools. Like, well, you need more parameters. In a two pool system, promote is always from "private" to "public". In a multi pool system, you need to specify earlier pool and later pool, and all the "in between" pools need to be updated as well, or possibly deleted. Actually a multi pool system..I'm not sure this works well. In particular because of $origin. In particular because the search for shared libraries doesn't necessarily follow analogously to cm3's search for packages. Well, ok, I admit, what probably works well is CM3_POOLs=pool1;pool2;pool3 LD_LIBRARY_PATH=pool1/lib;pool2/lib:pool3/lib Then you can have an arbitrary number of pools and they can all be sparse and you can imagine promoting just a package at a time. If you use $origin, pool/lib can't be sparse. Perhaps just pool/lib, but all the rest can be sparse. Do you promote packages or pools? I think you actually promote entire pools. Aha, see, this solves another problem. This solves cm3 being dynamically linked. Because you promote an entire pool at a time, multiple packages simultaneously, you don't have a new cm3 using an old m3core, because you would build both before any promote. This also fixes the problem where cm3 can't ship itself, because, something like, you never run anything in the first pool. (Similarly it removes the need to build things build_standalone because they run "unshipped". In fact, it makes it so runpath is just $origin/../lib is ok, it removes the problem of unshipped binaries living in a directory layout vs. shipped binaries). That defers to the problem. cm3 might be unable to promote itself. However, first of all, one many systems even NT you can rename and replace. Subsequent invocations can look for and delete the renamed copies. Also, promote might be a wrapper .sh/.cmd, runs the executable, which does most of the work, and leaves behind another .sh/.cmd for the wrapper to run as its last step. Any build output that is "shipped" today would instead be written to the first pool. Non-shipped build outputs, not sure. .o/.mo/.io files. There would probably be another "root" to indicated where unshipped outputs go. That way the entire source tree is kept clean, not just individual packages. > IMO it's OK to ship them all to one directory, but to make things > work for multi-architecture pools, we'd need to distinguish the > library and binary paths there, too. So we'd have something like This is a long-standing dilemna of mine. If multi-architecture pools are the goal, or you just use different roots. Or at least if you have multi-architecture host pools, or only multi-targets. Specifically, bin and lib historically lack architecture, while pkg has it. This should suffice for such a pool to target multiple architectures but not host on multiple architectures. I've long though that maybe root/bin should only contain .cmd/.py/.sh files that determine their host architecture and then run root/pkg/foo/target/foo. Note that this breaks $origin. You could use root/bin/target/foo, root/lib/target/foo and $origin/../../lib but I worry when there are too many ".." in $origin, you run the risk of "escaping" away from "your files" and out into whatever is in the file system. This is a constant dilemna for me because I mostly use a host that supports three Modula-3 hosts. My installation is at c:\cm3 and sometimes c:\cm3\bin\cm3.exe is Cygwin, sometimes it is NT386, and Interix uses c:\cm3\bin\cm3 with no extension. I don't have a clean workflow here. Either I should have c:\cm3 (native), c:\cm3.cygwin, c:\cm3.interix, or I should have c:\cm3\bin\nt386\cm3, c:\cm3\bin\cygwin\cm3, c:\cm3\bin\interix\cm3, or somesuch. Again, though, $origin is a factor here. c:\cm3.cygwin et. al. requires no changes and no concert wrt $origin. Olaf below advocates something more like c:\cm3\bin\nt386\cm3 and I don't disagree, I'm just not sure. "Repository" has many uses. It is "a place you put things". Often it is more like "well structured part of the file system", or deliberately structured. A pool is more like "a collection from which to draw stuff". - Jay > Date: Fri, 3 Jul 2009 11:22:05 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT > > Quoting Randy Coleburn : > > > Jay: > > > > Not sure I fully appreciate/understand your last 3 posts below. > > > > I'd also like to hear what Tony and Olaf think about all this. > > I think Jay chiefly opts for a long unimplemented wish of mine: > a hierarchy of repositories that is searched by the M3 builder. > Imagine that you can have one global repository, which contains > some standard and base packages and tools, and several project > repositories, each of which is used by teams whose members all have > private repositories for their own test and development purposes. > > A note on terminology: I don't really like to use the term > `repository' here, as it is usually used in connection with version > control systems. In ComPact, a tool developed and used years ago by > Elego, we called these `repositories' which contained pre-built packages > `package pools' or just `pools'. So I'll use that term instead of > repository from now on. > > The CM3 builder needs to be extended to search a set of pools > instead of just one (INSTALL_ROOT). This could be expressed by > a CM3_POOL_PATH, similar to the Java class path: > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 > > To satisfy package imports, the builder would start searching in the > first pool and continue until it has found an appropriate package. > This way local or project changes could easily be tested and integrated > before being `promoted' to a higher level. > > For backward compatibility reasons, there should be a default pool > (/usr/local/cm3) which is used when nothing else is defined. > > Shipping of packages would by default use the first pool found in the > CM3_POOL_PATH. > > The second extension needed would be the `promote' operation, which > ships a package from one pool to another pool. Of course CM3 would > need to make sure that all dependencies are correct and the shipped > package does actually work within the new context (the destination > pool's packages). > > If the package structure is the same in the workspace and in package > pools, standard shipping and promoting operations would just be > file copies (after appropriate correctness checks) as Jay says. > > Also, as Jay noticed, the `hack' of m3overrides wouldn't be > necessary any more. > > I don't think this would be too difficult to implement. I just haven't > found the time to do it yet ;-) > > Some further remarks to topics touched below: > > Shared libraries weren't in wide-spread use when the M3 package > systme was designed. Only few of the DEC SRC targets actually > contained support for them. > > IMO it's OK to ship them all to one directory, but to make things > work for multi-architecture pools, we'd need to distinguish the > library and binary paths there, too. So we'd have something like > > root/pkg/pkg-a/src > /NT386 > /I386_DARWIN > /pkg-b/src > /NT386 > /I386_DARWIN > /man > /bin/NT386 > /I386_DARWIN > ... > /lib/NT386 > /I386_DARWIN > ... > > Symbolic links were used for dynamic libraries by the related quake > code as long as I remember. > > The variable ROOT is legacy, I think it was used for overrides even > by DEC SRC. I've got no objection to rename it, but, as described above, > we should rather make it vanish. > > Olaf > > > Regards, > > Randy > > > >>>> 7/2/2009 9:57 PM >>> > > > > Ps this would also obsolete m3overrides, providing similar but > > better functionality, no need to encode the source structure in all > > those little extra files. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > > > > > > In particular I would argue that the directory layout should be made > > right at link time, into an alternate root. That alternate root > > possibly be prepopulated with links to or copies of the current good > > shared repository. Or the compiler should have notion of multiple > > roots to probe. However running the stuff implies hardlinks that are > > broken upon write. This scheme works better if source/interfaces > > are not needed in repository, just to cut down on the size. Are > > shipped source/interfaces used by compiler, or just the > > .m3exports/.m3x files? Anyway this is all thinking for a future > > release, not this year. 'ship' becomes just recursive copy or > > move.or change roots, plus maybe shipping source/interfaces too, > > kind of a wart. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > > > > > > The system used/uses symlinks under the covers. I don't think cm3 > > historically supported shared libs on hpux probably because the > > bundled compiler does not. Granted my exposure to hpux is only in > > recent times. 'standalone' as you define is useful but I think that > > reason isn't applicable to anything 'within cm3 itself'. Maybe more > > to say later. In particular I think this design we have is flawed. > > It's goals are good but can be better achieved slightly differently. > > In particular the unshipped and shipped directory layout should be > > 'the same' but just differently rooted. Not in this release though. > > That let's $origin work better, among other advantages. Related and > > possibly solved same IMHO we don't adequately separate source and > > output - it should separate across multiple packages not just one at > > a time. But again, not on this release. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > > > > > > I thought it might be helpful to highlight some of what I've always > > understood as the design for the CM3 package system. So, I pulled > > out my old documentation from Critical Mass as reference. > > > > I offer the following information to see if this discussion thread > > concurs and/or wants to make any changes going forward, esp. as we > > prepare for a new CM3 release. > > > > 1. CM3 takes care to separate source and derived files because > > doing so (a) isolates source files for backup, revision control, and > > searching; and (b) enables sharing the same source tree across > > operating systems and architectures, without confusing object files > > from different platforms. > > > > 2. Each package resides in a directory, with sources in a source > > subdirectory ("src"), and generated files in a derived subdirectory > > named to denote the platform on which the sources were built, e.g., > > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > > > 3. Each developer can have multiple private packages, each stored > > wherever desired in the filesystem. A private package named "foo" > > would have the following filesystem structure: > > +---foo > > | +---src > > | +---NT386 > > | +---HPPA > > | \---(...) > > > > 4. For each CM3 installation, there is one public package > > repository that is available to all developers. When you ship a > > [private] package, you make that package available to other packages > > (and developers) via this public package repository. The idea is > > that as a developer you would test your package in your private > > repository before shipping it to the public repository. (Sometimes > > m3overrides were needed when testing several related private > > packages before shipping them.) > > > > 5. A typical CM3 installation is rooted at a given point in the > > file system and contains the following folder structure: > > CM3 > > +---bin > > +---doc > > | +---help > > | +---pics > > | +---reference > > | +---src_reports > > | \---tutorial > > +---examples > > +---lib > > +---pkg > > | +---bitvector > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > | +---cm3ide > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > | +---(...) > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > > > 6. In the past, the environment variable INSTALL_ROOT pointed to > > the root of the CM3 tree in the file system. I think this variable > > is ambiguously named and that we should change it to > > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > > installations (perhaps for different releases), one would simply > > need to change the CM3_INSTALL_ROOT variable to point to the desired > > installation for use at any particular point in time. For this to > > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > > for the old cm3.cfg file, this was indeed the behavior. Then, if > > someone had a special situation, they could override the "cueing" > > behavior for any particular variable simply by changing its > > definition on the fly. > > > > 7. Now, I also understand some (but not all) of what Jay is saying > > about the library paths. Back in the old cm3 v4.1 days, I had both > > HPPA and NT386 derived files for the same set of sources. For > > Windows, the shipped exe and dll files went into the public > > repository and you needed to have the CM3/bin folder on your path. > > For private exe and dlls, you typically just ran them out of the > > private package's derived NT386 folder. On HPPA, there were some > > places in the file system that contained static libraries and shared > > libraries, plus then you had the libraries built using CM3. Again, > > the CM3 libraries went to the public repository and there were > > environment variables to facilitate finding the rest, including > > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > > operating environments seems to cloud up all this. I know I'm a bit > > rusty wrt all the various unix variants out there, but I recall > > that v4.1 worked out-of-the-box for both NT386 and HPPA with > > respect to all this library path stuff and I didn't have to make > > any symbolic links nor any hard links to make it work. IMO, links > > are bad and too easily broken. > > > > 8. As for "build_standalone", I know there are various > > build/bootstrap reasons why some parts of CM3 had to be built this > > way. But, for me, I've often used this feature for utility-type > > programs to make it easier to distribute them. I can simply > > distribute the one executable file without having to worry that the > > target system might not have the right DLLs or the right shared > > libraries in the right locations. For production code, I've always > > built an installation program or an installation script that > > installed all my executables and shared libraries in a folder > > structure rooted at a particular point chosen by the end user. > > Then, my programs always launched and used relative paths from the > > install location to find everything they needed. > > > > Hope this info is helpful. > > > > Regards, > > Randy Coleburn > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 15:46:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 13:46:24 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 15:53:29 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 13:53:29 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 16:19:02 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 14:19:02 +0000 Subject: [M3devel] FW: removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [trying again...truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 18:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 16:14:43 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [trying again again...truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 3 19:44:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 3 Jul 2009 13:44:34 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> Message-ID: On 2 Jul 2009, at 16:23, Jay wrote: > (I just didn't like the link stuff and I still don't understand > what ROOT is there for). > > The point was to add Unix.link where it belongs, m3core, and use it > from where can't depend on new m3core. > And maybe go overboard in sharing the source, to a trivial one > line function (less trivial on Win32, in order to support pre- > Win2000 OS). > The point was to put the files in lib and also leave them in pkg, > without wasting space. > The decision now, which I still have to try, is to stop putting the > files in pkg, so then no hardlink needed. Sounds good. > $origin vs. full paths is still debatable and I still convinced > $origin is the way to go. I agree $origin is best way to go. > I'm also inclined to put $origin and $origin/../lib in rpath, so > backups can flatten the structure to just one directory: > /backup/cm3 > /backup/libm3core.so > /backup/libm3.so Fair enough. > in some /hypothetical future/ where cm3 is dynamically linked. > As long there are no "duplicates" -- files in both bin and lib, the > runpath remains fairly clear/unambiguous. > And even then, the order is pretty clearly left to right.. Not sure I understand. > > - Jay > > > > > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 16:17:54 -0400 > > On 2 Jul 2009, at 16:03, Jay wrote: > > Ok, so I think a very important question is: > > >>> Should users have a choice of where to install? > > Yes! > > >>> What are the reasonable ramifications of someone who makes a > non-default choice? > > /Personally/ I want the choice, esp. if I don't have root access!, > and I don't want to set LD_LIBRARY_PATH. > I want my choice and no negative consequences, and $origin basically > gives me that. > Except NetBSD prior to 5.0. 5.0 already released. > And I guess Solaris prior to 2.7 or such. > > > We do agree on a change vs. previous releases, at least. > And it overlaps with what I did already. > > I think so. (I just didn't like the link stuff and I still don't > understand what ROOT is there for). > > > > > - Jay > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 15:59:25 -0400 > > I agree, LD_LIBRARY_PATH should only be used by power-users in a > pinch during development. > > On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 3 21:36:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 21:36:42 +0200 Subject: [M3devel] building m3gdb on AMD64_LINUX Message-ID: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> building m3gdb on birch ends with gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/tui/tui-winsource.c /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c c-exp.c.tmp -- yacc Cannot open "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" make[2]: *** [c-exp.c] Error 1 make[2]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' make[1]: *** [all-gdb] Error 2 make[1]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' make: *** [all] Error 2 "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile 4 /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args Fatal Error: package build failed Any hints? Wrong yacc? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 3 21:38:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 21:38:54 +0200 Subject: [M3devel] some testing of the new web pages In-Reply-To: References: Message-ID: <20090703213854.76mnwfvjms0w804c@mail.elegosoft.com> Quoting Jay : > I do like the new web pages. > Here are some problems though. Most of the problems below should be fixed now. I've removed packages tcl, mtex and PEX from the distribution, since I don't think they will be useful in their current form. Regards, Olaf > http://www.opencm3.net/releng/collection-core.html > > > go down to m3-sys/cm3 > the builder and freebsd manual page links aren't right. > I think these are maybe just CVS merge conflicts > that happen to be on the packaging machine and > can just be deleted. > > Not clear if most of the gcc links are useful. > > > go down to TCL interfaces for M3 > The browse sources link doesn't work. > Probably related to this not always building and not built. > Probably need to modify this and require people doing package building > to have Tcl installed, maybe even for NT386. > Probably specifically make-dist.sh should set $ENABLE_TCL or somesuch. > (not exactly) > > > The source links present, e.g. the licenses oddly, > but compactly and probably a good thing, e.g.: > http://www.opencm3.net/doc/help/gen_html/tcp/src/common/StreamRdClass.m3.html > Probably an artifact of m3tohtml. > > > http://www.opencm3.net/releng > Go down the righthand side trying everything to one level. > Broken: > http://www.opencm3.net/releng/collection-min.html > http://www.opencm3.net/releng/collection-caltech.html > > > But there is: > http://www.opencm3.net/releng/collection-caltech-parser.html > It contains m3-win/import-libs but shouldn't. > > > I suspect the problems are rooted in: > min is a non-ws package set but not a ws package set. > Because it is overlys small and core subsumes it? > caltech-parser contains a dash. > min to me is specifically enough to start with an old release and > build a current compiler and release -- m3core, libm3, m3cg, cm3, > maybe sysutils > specifically it is the pieces required to compile anything (cm3, m3cg) > and the pieces that an old compiler may not be able to build the > the current versions of (m3core/libm3) that a current compiler will need; > That is, if you want to build natively build the whole system from source, > this is the smallest you can start with. m3cg actually isn't in min but > probably handled specially. > > > Related couments usually but not always > has one extra empty bullet, including but not limited > to when the list is empty: > > http://www.opencm3.net/releng/collection-cvsup.html > http://www.opencm3.net/releng/collection-anim.html > http://www.opencm3.net/releng/collection-cvsup.html > http://www.opencm3.net/releng/collection-database.html > http://www.opencm3.net/releng/collection-demo.html > http://www.opencm3.net/releng/collection-devlib.html > http://www.opencm3.net/releng/collection-game.html > http://www.opencm3.net/releng/collection-gui.html > > This is not all the ones with an extra bullet, and a few > don't have the extra bullet. > > I'm on the fence on the whole ws thing. > Non-ws also has matching source. > The point is to provide the packages both built > and buildable? > If cm3 had a mode that started with assemble then link and ship, > we could cross build all the ws packages, very nice. > > I guess the "real" problem is I feel compelled then to > match this feature in make-dist.py. > > http://www.opencm3.net/releng/collection-tool.html > Try the first few links. > mtex > Browse sources seems incomplete but maybe is right. > The man page links are all broken. > > cmpdir > shows a general pattern: > maybe directories with no files shouldn't be shown? > > http://www.opencm3.net/releng/collection-demo.html > fisheye > The link manual page .makefile isn't right > > > http://www.opencm3.net/releng/collection-devlib.html > m3tk > Several broken manpage links. > > pex > browse sources doesn't work > Probably like Tcl, not always built. > > > http://www.opencm3.net/releng/collection-anim.html > zeus > contains a broken Zeus manual page, I think a CVS conflict file > Might be able to search for this generally in the html. > > http://www.opencm3.net/releng/collection-obliq.html > related documents > first link, to polymtl, broken, sounds promising, maybe > we can find it and host it > > http://www.opencm3.net/releng/collection-m3gdb.html > m3gdb > Like m3cc, maybe some of these READMEs not useful. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Fri Jul 3 23:53:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 03 Jul 2009 16:53:31 -0500 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> Message-ID: <4A4E7DDB.2090107@cox.net> On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc is circuitously symlinked to a script that executes /usr/bin/bison -y. In any case, usually, there is no need to execute yacc when building (m3)gdb, because its output is already present and newer than yacc's input, in this case, c-exp.y. I think this is the way it is in the CVS repository. Did some dates in your source copy get touched? I have no idea where the c-exp.t file it wants is supposed to come from. In a brief look, I didn't find any reference to a *.t file at all, either in the script m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the bison man page on my machine). Maybe original yacc does something with it. I would have thought ylwrap would have been written to work with a number of varieties of yacc and equivalents. Do you have a copy of c-exp.y? I suspect having a newer c-exp.c than c-exp.y will circumvent this problem, but of course we probably want it set up to work when c-exp.c needs to be rebuilt. Olaf Wagner wrote: > building m3gdb on birch ends with > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > -Wformat-nonliteral -Wunused-label -Wunused-function > ../../gdb/gdb/tui/tui-winsource.c > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > c-exp.c.tmp -- yacc > Cannot open > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > make[2]: *** [c-exp.c] Error 1 > make[2]: Leaving directory > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > make[1]: *** [all-gdb] Error 2 > make[1]: Leaving directory > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > make: *** [all] Error 2 > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > --procedure-- -line- -file--- > exec -- > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > 4 > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > Any hints? Wrong yacc? > > Olaf From hendrik at topoi.pooq.com Sat Jul 4 01:12:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Jul 2009 19:12:54 -0400 Subject: [M3devel] multiarch Message-ID: <20090703231254.GA25415@topoi.pooq.com> It seems relevant to out multiarchitecture system that Debian and Ubuntu are currently also struggling to put together a multiarchitecture system. Current thinking seems to be posted at https://wiki.ubuntu.com/MultiarchSpec The stimulus for this work seems to be having 32-bit and 64-bit programs coexist on the same AMD-64 system. But it also deals with questions like MIPS systems having at least three different ABIs. Have a look. -- hendrik From hendrik at topoi.pooq.com Sat Jul 4 01:15:09 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Jul 2009 19:15:09 -0400 Subject: [M3devel] multiarch In-Reply-To: <20090703231254.GA25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> Message-ID: <20090703231509.GB25415@topoi.pooq.com> On Fri, Jul 03, 2009 at 07:12:54PM -0400, hendrik at topoi.pooq.com wrote: > > The stimulus for this work seems to be having 32-bit and 64-bit programs > coexist on the same AMD-64 system. But it also deals with questions > like MIPS systems having at least three different ABIs. They're also considering interpreters like Python to be architectures to be supported. -- hendrik From jay.krell at cornell.edu Sat Jul 4 08:48:19 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 06:48:19 +0000 Subject: [M3devel] multiarch In-Reply-To: <20090703231509.GB25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> Message-ID: The Python thing as I understand it, is that sometimes package foo depends on package bar, and they must be of the same architecture, and sometimes not. Specifically inproc "plugins" require matching architecture, but if I just run an executable, architecture doesn't usually have to match. OpenBSD sets an interesting counterexample -- no biarch/multiarch, just one architecture, "same as it ever was", "no additional complexity", "everything is built from source anyway". - Jay > Date: Fri, 3 Jul 2009 19:15:09 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiarch > > On Fri, Jul 03, 2009 at 07:12:54PM -0400, hendrik at topoi.pooq.com wrote: > > > > The stimulus for this work seems to be having 32-bit and 64-bit programs > > coexist on the same AMD-64 system. But it also deals with questions > > like MIPS systems having at least three different ABIs. > > They're also considering interpreters like Python to be architectures to > be supported. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:28:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <4A4E7DDB.2090107@cox.net> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:33:48 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:33:48 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: It built ok for me a second time. The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb. yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means. You might just try rm -rf m3gdb and cvs -z3 upd -dAP. Maybe there is/was a timestamp problem. As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: Re: [M3devel] building m3gdb on AMD64_LINUX It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:35:51 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:35:51 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: See also C:\dev2\cm3.2\caltech-parser\parserlib\klex\src From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Subject: RE: [M3devel] building m3gdb on AMD64_LINUX Date: Sat, 4 Jul 2009 15:33:48 +0000 It built ok for me a second time. The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb. yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means. You might just try rm -rf m3gdb and cvs -z3 upd -dAP. Maybe there is/was a timestamp problem. As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: Re: [M3devel] building m3gdb on AMD64_LINUX It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 4 19:02:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 4 Jul 2009 13:02:37 -0400 Subject: [M3devel] multiarch In-Reply-To: References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> Message-ID: <20090704170237.GB26647@topoi.pooq.com> On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote: > > The Python thing as I understand it, is that sometimes package foo > depends on package bar, and they must be of the same architecture, and > sometimes not. Specifically inproc "plugins" require matching > architecture, but if I just run an executable, architecture doesn't > usually have to match. An executable has to be one of the architectures the processor will handle. And if it uses shared libraries, they have to have matching architecture. The whole worry about multiarch on Linux AMD-64 is to have a consistent way of identifying the compatible one of a set of same-names libraries, and doing this in such a way that it generalises to more architectures (because they *will* eventually show up) and won't confuse the package manager. I think the real point with python is that python code is architecture-independent, because it's handled by an architecture-dependent interpreter. Which makes it, in effect, an extra architecture that's available everywhere, whether you have an AMD-64 or other multiarch CPU or not. > OpenBSD sets an interesting counterexample -- no biarch/multiarch, > just one architecture, "same as it ever was", "no additional > complexity", everything is built from source anyway". And they probably do not in any way support 32-bit proprietary binary-only device drivers or Flash interpreters or anything like that on AMD-64. Building from source is the traditional Modula-3 way of handling packages. To do this with the Debian package-manager, we'd have to include an install-dependency on cm3-min and let the post-install script use the compiler to compile the package and ship it to the proper place. How to do this multiarch is not clear -- We might end up with a number of different architecture versions of the packages, which have identical contents (they're source code). Being labelled with different architectures might (here's hoping the multiarch project thinks of this) end up invoking the appropriate cm3-min binary ... I suspect having real binary packages for different architectures is the Debian way, however. Using source packages is the norm on gentoo. And cm3-min would have to be binary in any case, otherwise there would be no way to compile it. But the multiarch stuff might indicate where we want to ship our libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 or whatever the multiarch people choose. We're already using similar conventions in the choince of LINUXLIBC6 and such names. -- hendrik From mika at async.caltech.edu Sat Jul 4 19:21:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 04 Jul 2009 10:21:11 -0700 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: Your message of "Sat, 04 Jul 2009 15:33:48 -0000." Message-ID: <200907041721.n64HLCr7015429@taps.cs.caltech.edu> I guarantee that this "yacc" is not a faithful yacc. "k" is the first initial of Karl Papadantonakis, the caltech-parser package's author. Mika Jay writes: >--_682f6248-704f-461d-9237-1a192e95b6fb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >It built ok for me a second time. > >The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-= >cvs-uped m3-sys/m3gdb. > >=20 > >yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. > >=20 > >As long as nothing depend on running it by that name=2C and assuming it isn= >'t a faithful replacement for other Yacc's=2C probably should rename it m3y= >acc=2C or kyacc=2C whatever that means. > >=20 > >You might just try rm -rf m3gdb and cvs -z3 upd -dAP. > >Maybe there is/was a timestamp problem. > >As Rodney said=2C it shouldn't need to run yacc=2C even if your yacc is mes= >sed up. > >=20 > > - Jay > >=20 > > >From: jay.krell at cornell.edu >To: rodney.m.bates at cox.net=3B m3devel at elegosoft.com >Date: Sat=2C 4 Jul 2009 15:28:24 +0000 >Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > > >It built ok for me=2C but there is a suspicous /usr/local/cm3/bin/yacc. >I'm investigating more=2C but maybe not right now. >=20 > - Jay > >=20 >> Date: Fri=2C 3 Jul 2009 16:53:31 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] building m3gdb on AMD64_LINUX >>=20 >> On my AMD64_LINUX machine (Ubuntu 8.04.2)=2C on which m3gdb builds=2C yac= >c >> is circuitously symlinked to a script that executes /usr/bin/bison -y. >>=20 >> In any case=2C usually=2C there is no need to execute yacc when building= >=20 >> (m3)gdb=2C >> because its output is already present and newer than yacc's input=2C in=20 >> this case=2C >> c-exp.y. I think this is the way it is in the CVS repository. Did some=20 >> dates >> in your source copy get touched? >>=20 >> I have no idea where the c-exp.t file it wants is supposed to come from. >> In a brief look=2C I didn't find any reference to a *.t file at all=2C=20 >> either in the script >> m3gdb/gdb/ylwrap=2C nor in the yacc man page (which actually leads to the >> bison man page on my machine). Maybe original yacc does something=20 >> with it.=20 >> I would have thought ylwrap would have been written to work with a number >> of varieties of yacc and equivalents.=20 >>=20 >> Do you have a copy of c-exp.y? >>=20 >> I suspect having a newer c-exp.c than c-exp.y will circumvent this=20 >> problem=2C but >> of course we probably want it set up to work when c-exp.c needs to be=20 >> rebuilt. >>=20 >> Olaf Wagner wrote: >> > building m3gdb on birch ends with >> > >> > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config=20 >> > -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -DHAVE_CONFIG_H=20 >> > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/..=20 >> > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl=20 >> > -I../../gdb/gdb/../intl -DMI_OUT=3D1 -DTUI=3D1 -Wimplicit -Wreturn-type= >=20 >> > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith=20 >> > -Wformat-nonliteral -Wunused-label -Wunused-function=20 >> > ../../gdb/gdb/tui/tui-winsource.c >> > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c=20 >> > c-exp.c.tmp -- yacc >> > Cannot open=20 >> > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp= >.t"=20 >> > >> > make[2]: *** [c-exp.c] Error 1 >> > make[2]: Leaving directory=20 >> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' >> > make[1]: *** [all-gdb] Error 2 >> > make[1]: Leaving directory=20 >> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' >> > make: *** [all] Error 2 >> > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile"=2C line 121: quake= >=20 >> > runtime error: exit 2: make CC=3D"gcc" CFLAGS=3D"-g" MAKEINFO=3Decho >> > >> > --procedure-- -line- -file--- >> > exec -- >> > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> > 4=20 >> > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args >> > >> > Fatal Error: package build failed >> > >> > Any hints? Wrong yacc? >> > >> > Olaf >>=20 > >--_682f6248-704f-461d-9237-1a192e95b6fb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >It built ok for me a second time.
>The =3Bsecond time I removed /usr/local/cm3/bin from =3B$PATH and d= >eleted and re-cvs-uped m3-sys/m3gdb.
> =3B
>yacc =3Bcomes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src.> > =3B
>As long as nothing depend on running it by that name=2C and assuming it isn= >'t a faithful =3Breplacement for other Yacc's=2C probably should rename= > it m3yacc=2C or kyacc=2C whatever that means.
> =3B
>You might just try rm -rf m3gdb and cvs -z3 upd -dAP.
>Maybe there is/was a timestamp problem.
>As Rodney said=2C it shouldn't need to run yacc=2C even if your yacc is mes= >sed up.
> =3B
> =3B - Jay

 =3B
>
>From: jay.krell at cornell.edu
To: rodney.m.bates at cox.net=3B m3devel at elegos= >oft.com
Date: Sat=2C 4 Jul 2009 15:28:24 +0000
Subject: Re: [M3devel]= > building m3gdb on AMD64_LINUX

> >It built ok for me=2C but there is a =3Bsuspicous /usr/local/cm3/bin/ya= >cc.
I'm =3Binvestigating more=2C but =3Bmaybe not right now.
= > =3B
 =3B- Jay

 =3B
>=3B Date: Fri=2C 3 Jul 2009= > 16:53:31 -0500
>=3B From: rodney.m.bates at cox.net
>=3B To: m3deve= >l at elegosoft.com
>=3B Subject: Re: [M3devel] building m3gdb on AMD64_LI= >NUX
>=3B
>=3B On my AMD64_LINUX machine (Ubuntu 8.04.2)=2C on wh= >ich m3gdb builds=2C yacc
>=3B is circuitously symlinked to a script th= >at executes /usr/bin/bison -y.
>=3B
>=3B In any case=2C usually= >=2C there is no need to execute yacc when building
>=3B (m3)gdb=2C>>=3B because its output is already present and newer than yacc's input= >=2C in
>=3B this case=2C
>=3B c-exp.y. I think this is the way i= >t is in the CVS repository. Did some
>=3B dates
>=3B in your sou= >rce copy get touched?
>=3B
>=3B I have no idea where the c-exp.t= > file it wants is supposed to come from.
>=3B In a brief look=2C I did= >n't find any reference to a *.t file at all=2C
>=3B either in the scr= >ipt
>=3B m3gdb/gdb/ylwrap=2C nor in the yacc man page (which actually = >leads to the
>=3B bison man page on my machine). Maybe original yacc d= >oes something
>=3B with it.
>=3B I would have thought ylwrap wo= >uld have been written to work with a number
>=3B of varieties of yacc = >and equivalents.
>=3B
>=3B Do you have a copy of c-exp.y?
&g= >t=3B
>=3B I suspect having a newer c-exp.c than c-exp.y will circumve= >nt this
>=3B problem=2C but
>=3B of course we probably want it s= >et up to work when c-exp.c needs to be
>=3B rebuilt.
>=3B
&g= >t=3B Olaf Wagner wrote:
>=3B >=3B building m3gdb on birch ends with<= >BR>>=3B >=3B
>=3B >=3B gcc -c -g -I. -I../../gdb/gdb -I../../gdb= >/gdb/config
>=3B >=3B -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -= >DHAVE_CONFIG_H
>=3B >=3B -I../../gdb/gdb/../include/opcode -I../../= >gdb/gdb/../readline/..
>=3B >=3B -I../bfd -I../../gdb/gdb/../bfd -I= >../../gdb/gdb/../include -I../intl
>=3B >=3B -I../../gdb/gdb/../int= >l -DMI_OUT=3D1 -DTUI=3D1 -Wimplicit -Wreturn-type
>=3B >=3B -Wcomme= >nt -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith
>=3B >=3B -Wf= >ormat-nonliteral -Wunused-label -Wunused-function
>=3B >=3B ../../g= >db/gdb/tui/tui-winsource.c
>=3B >=3B /bin/sh ../../gdb/gdb/../ylwrap= > ../../gdb/gdb/c-exp.y y.tab.c
>=3B >=3B c-exp.c.tmp -- yacc
>= >=3B >=3B Cannot open
>=3B >=3B "/home/wagner/work/cm3/m3-sys/m3gd= >b/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t"
>=3B >=3B
>=3B >=3B= > make[2]: *** [c-exp.c] Error 1
>=3B >=3B make[2]: Leaving directory= >
>=3B >=3B `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb'
= >>=3B >=3B make[1]: *** [all-gdb] Error 2
>=3B >=3B make[1]: Leav= >ing directory
>=3B >=3B `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_L= >INUX'
>=3B >=3B make: *** [all] Error 2
>=3B >=3B "/home/wagn= >er/work/cm3/m3-sys/m3gdb/src/m3makefile"=2C line 121: quake
>=3B >= >=3B runtime error: exit 2: make CC=3D"gcc" CFLAGS=3D"-g" MAKEINFO=3Decho>>=3B >=3B
>=3B >=3B --procedure-- -line- -file---
>=3B >= >=3B exec -- <=3Bbuiltin>=3B
>=3B >=3B m3gdb_Run 121 /home/wagner= >/work/cm3/m3-sys/m3gdb/src/m3makefile
>=3B >=3B include_dir 160 /hom= >e/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile
>=3B >=3B 4
>=3B= > >=3B /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args
>= >=3B >=3B
>=3B >=3B Fatal Error: package build failed
>=3B >= >=3B
>=3B >=3B Any hints? Wrong yacc?
>=3B >=3B
>=3B >= >=3B Olaf
>=3B
>= > >--_682f6248-704f-461d-9237-1a192e95b6fb_-- From jay.krell at cornell.edu Sat Jul 4 19:24:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 17:24:24 +0000 Subject: [M3devel] multiarch In-Reply-To: <20090704170237.GB26647@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> <20090704170237.GB26647@topoi.pooq.com> Message-ID: I think Python code simply depends on the Python interpreter. I skimmed through the document. The point I gleaned about interpreters is that sometimes a dependency is on an interpreter because the package is a "plugin" or "extension" written in C or such, and sometimes the dependency is because a program is written in "pure" Python (Tcl, Perl, etc.) and just needs "any" interpreter that will run. That is, if I have: hello.py: print("hello") I am dependent on Python, but on an AMD64 system, it can be the x86 Python or AMD64 Python (or heck, Jython or IronPython, implementations in Java and for .NET/Mono). I see your point that Python could be considered an "architecture" and the Python interpreter could be seen as installing the processor. I didn't get that from the spec but should read it more closely. There were some references here to qemu that I didn'd understand but might make sense in that light. That is, maybe, maybe I could have "all architectures" in one file system and maybe some virtualization products use the host file system as a file system and not just store some virtual disk in it. I agree OpenBSD is a bit spartan/draconion/etc. My point about source builds was more to reflect the seeming "OpenBSD way" (Gentoo, SourceMage, etc.), not necessarily what is or should be the Modula-3 way. There's a real dilemna between the two options of binary packages and source builds. They each have advantages/disadvantages. - Jay > Date: Sat, 4 Jul 2009 13:02:37 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiarch > > On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote: > > > > The Python thing as I understand it, is that sometimes package foo > > depends on package bar, and they must be of the same architecture, and > > sometimes not. Specifically inproc "plugins" require matching > > architecture, but if I just run an executable, architecture doesn't > > usually have to match. > > An executable has to be one of the architectures the processor will > handle. And if it uses shared libraries, they have to have matching > architecture. The whole worry about multiarch on Linux AMD-64 is to > have a consistent way of identifying the compatible one of a set > of same-names libraries, and doing this in such a way that it > generalises to more architectures (because they *will* eventually show > up) and won't confuse the package manager. > > I think the real point with python is that python code is > architecture-independent, because it's handled by an > architecture-dependent interpreter. Which makes it, in effect, an > extra architecture that's available everywhere, whether you have an > AMD-64 or other multiarch CPU or not. > > > OpenBSD sets an interesting counterexample -- no biarch/multiarch, > > just one architecture, "same as it ever was", "no additional > > complexity", everything is built from source anyway". > > And they probably do not in any way support 32-bit proprietary > binary-only device drivers or Flash interpreters or anything like that > on AMD-64. > > Building from source is the traditional Modula-3 way of handling > packages. To do this with the Debian package-manager, we'd have to > include an install-dependency on cm3-min and let the post-install > script use the compiler to compile the package and ship it to the > proper place. > > How to do this multiarch is not clear -- We might end up with a number > of different architecture versions of the packages, which have identical > contents (they're source code). Being labelled with different > architectures might (here's hoping the multiarch project thinks of this) > end up invoking the appropriate cm3-min binary ... > > I suspect having real binary packages for different architectures is the > Debian way, however. Using source packages is the norm on gentoo. > And cm3-min would have to be binary in any case, otherwise there would > be no way to compile it. > > But the multiarch stuff might indicate where we want to ship our > libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 > or whatever the multiarch people choose. We're already using similar > conventions in the choince of LINUXLIBC6 and such names. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 4 19:55:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 04 Jul 2009 19:55:21 +0200 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <4A4E7DDB.2090107@cox.net> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: <20090704195521.1g2ictqykgocc0sg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did > some dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. I would have thought ylwrap would have been written to work > with a number > of varieties of yacc and equivalents. Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to > be rebuilt. I now removed everything, including the source, and checked out the package anew. Then the build completed without problems. Thanks for the help, Olaf > Olaf Wagner wrote: >> building m3gdb on birch ends with >> >> gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config >> -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H >> -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. >> -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include >> -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit >> -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses >> -Wpointer-arith -Wformat-nonliteral -Wunused-label >> -Wunused-function ../../gdb/gdb/tui/tui-winsource.c >> /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c >> c-exp.c.tmp -- yacc >> Cannot open >> "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" >> make[2]: *** [c-exp.c] Error 1 >> make[2]: Leaving directory >> `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' >> make[1]: *** [all-gdb] Error 2 >> make[1]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' >> make: *** [all] Error 2 >> "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: >> quake runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo >> >> --procedure-- -line- -file--- >> exec -- >> m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> 4 >> /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args >> >> Fatal Error: package build failed >> >> Any hints? Wrong yacc? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sun Jul 5 21:36:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 5 Jul 2009 15:36:06 -0400 Subject: [M3devel] multiarch In-Reply-To: References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> <20090704170237.GB26647@topoi.pooq.com> Message-ID: <20090705193606.GA31710@topoi.pooq.com> On Sat, Jul 04, 2009 at 05:24:24PM +0000, Jay wrote: > > My point about source builds was more to reflect the seeming "OpenBSD > way" (Gentoo, SourceMage, etc.), not necessarily what is or should be > the Modula-3 way. There's a real dilemna between the two options of > binary packages and source builds. They each have > advantages/disadvantages. One of the differences is that with a binary package, if we fix a big in the compiler package that might affect object code, it is necessary to produce new versions of all the packages that were compiled with it. If we have source packages, the package manager will have to discover that recompilation is necessary. And if we send source packages masquerading as binary packages (via post-install scripts or some such) we have to rerelease identical packages with a new version number, just to ensure recompilation. It seems that the thing to do is build packages that match the target system's predilections. If there are too many target systems, we'll have to do is our way and ignore the target system's conventions. Or maybe provide special packagings for a few important platforms. I gather that Windows is such a system. And I'm hoping Debian is. In any case, the compiler itself will have to be a binary package, because of bootstrapping. I think this discussion is starting to belabor the obvious. Is it useful to go on? I started this thread merely to report that others are starting to deal with multiarchitecture issues, and we might as well be aware of what they're doing. -- hendrik From eiserlohpp at yahoo.com Mon Jul 6 19:00:19 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 6 Jul 2009 10:00:19 -0700 (PDT) Subject: [M3devel] WDROOT private repository not working? Message-ID: <67172.22662.qm@web56806.mail.re3.yahoo.com> Hi Guys, Seeing all the attention placed on creating relative linking, and so forth, I decided to examine the behavior of CM3, when building for a private root. So, I set WDROOT to ${HOME}/m3work in my m3makefile. ---- BEGIN m3makefile ---- %# Time-Space-Position Information (TSPI) library HOME = "/home/peter" WDROOT = HOME & "/m3work" include_dir("xform") % include_dir("smoothing") % include_dir("editing") % include_dir("geoid") % include_dir("testing") ---- EMD m3makefile ---- Then I, attempted to build and ship from there. It said, there was an error ---- BEGIN ERROR MSG ---- peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship --- shipping from ../AMD64_LINUX --- "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/usr/lib/cm3/pkg/tspi": errno=13 --procedure-- -line- -file--- make_dir -- 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP ---- END ERROR MSG ---- Was support for WDROOT removed? Can CM3 support the ability to have a private repository, while also having the public repo? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Mon Jul 6 20:49:21 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 6 Jul 2009 11:49:21 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 33, Issue 25 Message-ID: <208085.23533.qm@web56807.mail.re3.yahoo.com> Hi Olaf, > Date: Fri, 03 Jul 2009 11:22:05 +0200 > From: Olaf Wagner > Subject: [M3devel] Some comments about package structure > and package > pools, was: > Re: ROOT > To: m3devel at elegosoft.com > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com> > Content-Type: text/plain; charset=ISO-8859-15; >The CM3 builder needs to be extended to search a set of pools >instead of just one (INSTALL_ROOT). This could be expressed by >a CM3_POOL_PATH, similar to the Java class path: > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 Yes, I like it. I could then ship my data reduction libraries to an appropriate "pool", and then all the different programs that make use of those libraries, can access them. This would not require "root" privileges. If this were a work group pool, then it would only need "group" ones. If a private pool such as ${HOME}/m3work (the old WDROOT), I wouldn't need any special privileges. How would we specify the pool to which we desire to ship? Command line argument? --pool-install-path=${MYPROJECT}/m3pool -p ${MYPROJECT}/m3pool Environment Variable? M3_INSTALL_POOL=${MYPROJECT}/m3pool > >To satisfy package imports, the builder would start searching in the >first pool and continue until it has found an appropriate package. >This way local or project changes could easily be tested and integrated >before being `promoted' to a higher level. > >For backward compatibility reasons, there should be a default pool >(/usr/local/cm3) which is used when nothing else is defined. We could also make use of the paths built into M3Config, as part of the default search pool path. That is the reason that M3Config exists, so M3 programs can find at run-time the main installation pool, and its components (bin, lib, pkg, ..., etc). +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Mon Jul 6 22:17:03 2009 From: jay.krell at cornell.edu (Jay lastname) Date: Mon, 6 Jul 2009 20:17:03 +0000 Subject: [M3devel] WDROOT private repository not working? In-Reply-To: <67172.22662.qm@web56806.mail.re3.yahoo.com> References: <67172.22662.qm@web56806.mail.re3.yahoo.com> Message-ID: I think WDROOT was only ever a synonym for ROOT -- the root of the source tree, available for overrides to get "builtlocal" unshipped stuff. This does somewhat resemble what Olaf was talking about, but it is referencing, essentially, the source tree, in a different layout than the shipped tree. Instead Olaf and I advocate multiple (I think two is maybe enough) roots with the same layout as the shipped/installed system, instead of one shipped and one unshipped. All outputs that would be shipped should just go to this place, rather than first to build_dir and then later copied into the right layout. They might still be copied, but it would not be a layout changing copy. (And yes, this mechanism does work.) Searching for 'wdroot'... C:\dev2\cm3.2\m3-db\stable\example\src\m3makefile(7):override ("stable", WDROOT) % try to pick up the local copy C:\dev2\cm3.2\m3-libs\arithmetic\test\src\m3overrides(1):%override("arithmetic",WDROOT) C:\dev2\cm3.2\m3-libs\lapack\test\src\m3overrides(1):%override("lapack",WDROOT) C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(350):.BR WDROOT , C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(516):.B WDROOT C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(554):.B WDROOT C:\dev2\cm3.2\m3-sys\m3loader\src\m3makefile(10): override ("winlib", WDROOT) C:\dev2\cm3.2\m3-tools\m3tk\src\files\m3overrides.not(1):override(m3tk-misc.3.1, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(9):% override ("vbtkit", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(10):% override ("formsvbt", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(11):%override ("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(12):%override ("juno-compiler", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\src\m3overrides(10):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\compiler\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\compiler\src\m3overrides(10):%override("juno-compiler", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\lexer\src\m3overrides(9):override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\lexer\src\m3overrides(10):override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\parser\src\m3overrides(9):%override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\parser\src\m3overrides(10):%override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\scope\src\m3overrides(9):%override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\scope\src\m3overrides(10):%override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\linear\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\nonlinear\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\runtime\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\solve\src\m3overrides(3):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-www\http\src\m3makefile(7):%write("WDROOT = ", WDROOT, CR) 26 occurrence(s) have been found. - Jay > Date: Mon, 6 Jul 2009 10:00:19 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] WDROOT private repository not working? > > > Hi Guys, > > Seeing all the attention placed on creating relative > linking, and so forth, I decided to examine the behavior > of CM3, when building for a private root. > > So, I set WDROOT to ${HOME}/m3work in my m3makefile. > > ---- BEGIN m3makefile ---- > %# Time-Space-Position Information (TSPI) library > > HOME = "/home/peter" > WDROOT = HOME & "/m3work" > > include_dir("xform") > % include_dir("smoothing") > % include_dir("editing") > % include_dir("geoid") > % include_dir("testing") > ---- EMD m3makefile ---- > > > Then I, attempted to build and ship from there. > > It said, there was an error > > ---- BEGIN ERROR MSG ---- > peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship > --- shipping from ../AMD64_LINUX --- > > "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/usr/lib/cm3/pkg/tspi": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP > > ---- END ERROR MSG ---- > > > > Was support for WDROOT removed? Can CM3 support the ability to > have a private repository, while also having the public repo? > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 6 22:31:02 2009 From: jay.krell at cornell.edu (Jay lastname) Date: Mon, 6 Jul 2009 20:31:02 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <208085.23533.qm@web56807.mail.re3.yahoo.com> References: <208085.23533.qm@web56807.mail.re3.yahoo.com> Message-ID: Just fyi..I see this all maybe slightly differently. I'm not sure it works well beyond two pools. I'm not sure it works well with sparse pools -- particularly if $ORIGIN is used. Roughly I see it that there are two pools, ROOT/pkg and CM3_INSTALL/pkg. You build into ROOT/pkg and ship from ROOT/pkg to CM3_INSTALL/pkg. Ship, or promote, is possibly an entire pkg store to pkg store operation, not individual packages. If you remove the use of origin, then it might become easier to use multiple pools and sparse pool, however, imagine you build and ship a private m3core.so. Which programs and .so files are supposed to use that? If that is only the thing you build/ship, nothing will use it. Arguably that is correct, since nothing has been built against its possibly changed interfaces. Arguably all pools must be built up from the bottom of the dependency tree and on up. And the only allowed "sparseness" is that you don't "finish". This strikes at why you can't ship after buildlocal. That isn't the right restriction -- if you buildlocal "everything", then you have coherence and should be able to ship everything (but not selectively). However, now I painted ourselves into a perhaps less interesting corner and in fact the same place we already are -- you can always build up a new package store from scratch from the bottom of the dependency tree and on up. You can always put together a system as non-root. Now, let's consider if $ORIGIN is removed. In fact, by default we use $ORIGIN and full paths. Now you can have sparse or incomplete package stores but you have to be careful. I'm not sure how to formulate what the restrictions are, but for example, if you were to build and ship out of dependency order, you could end up with a system where multiple versions of the "same" .so files are in use, and it might or might not matter. You could have pkg1/m3core.so pkg1/libm3.so pkg2/m3core.so pkg2/libm3.so pkg2/libfoo.so pkg2/libbar.so libbar.so might depend on pkg1/libm3.so and pkg1/m3core.so and libfoo.so might depend on pkg2/libm3.so, pkg2/m3core.so. Depending on the order you built/shipped in. If libbar.so and libfoo.so never pass types to each other defined in m3core, then this is probably ok. However you might end up with multiple garbage collectors trying to free the same storage. I suggested that each package store be created by cloning the next one in the list. That helps address these situations. But "clone" vs. build from scratch from the bottom of the dependency tree and on up are, are similar. - Jay > Date: Mon, 6 Jul 2009 11:49:21 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 25 > > > Hi Olaf, > > > > Date: Fri, 03 Jul 2009 11:22:05 +0200 > > From: Olaf Wagner > > Subject: [M3devel] Some comments about package structure > > and package > > pools, was: > > Re: ROOT > > To: m3devel at elegosoft.com > > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com> > > Content-Type: text/plain; charset=ISO-8859-15; > > > >The CM3 builder needs to be extended to search a set of pools > >instead of just one (INSTALL_ROOT). This could be expressed by > >a CM3_POOL_PATH, similar to the Java class path: > > > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 > > Yes, I like it. I could then ship my data reduction > libraries to an appropriate "pool", and then all the > different programs that make use of those libraries, > can access them. This would not require "root" privileges. > If this were a work group pool, then it would only need > "group" ones. If a private pool such as ${HOME}/m3work > (the old WDROOT), I wouldn't need any special privileges. > > How would we specify the pool to which we desire to ship? > Command line argument? > > --pool-install-path=${MYPROJECT}/m3pool > -p ${MYPROJECT}/m3pool > > Environment Variable? > M3_INSTALL_POOL=${MYPROJECT}/m3pool > > > > > >To satisfy package imports, the builder would start searching in the > >first pool and continue until it has found an appropriate package. > >This way local or project changes could easily be tested and integrated > >before being `promoted' to a higher level. > > > >For backward compatibility reasons, there should be a default pool > >(/usr/local/cm3) which is used when nothing else is defined. > > We could also make use of the paths built into M3Config, > as part of the default search pool path. That is the > reason that M3Config exists, so M3 programs can find at > run-time the main installation pool, and its components > (bin, lib, pkg, ..., etc). > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Tue Jul 7 02:49:36 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Mon, 6 Jul 2009 20:49:36 -0400 Subject: [M3devel] multiple pkg roots In-Reply-To: References: <208085.23533.qm@web56807.mail.re3.yahoo.com> Message-ID: <4A526360.1E75.00D7.1@scires.com> >From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose. The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--ie. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight. Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose. Perhaps my understanding of what is meant by "pool" needs clarification? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Tue Jul 7 06:49:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 04:49:19 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <4A526360.1E75.00D7.1@scires.com> References: <208085.23533.qm@web56807.mail.re3.yahoo.com> <4A526360.1E75.00D7.1@scires.com> Message-ID: I believe these two things are highly related. When you have a multiple pool environment, you must be careful what you replace and in what order. Otherwise you end up with inconsistencies. As well, you possibly need a "runpath" that includes every pool -- i.e. you can't use $ORIGIN, you maybe can, maybe should not use full paths in runpath, probably using an LD_LIBRARY_PATH that shadows the pool list is what people expect. OR, what I described: you don't have any incomplete pools. Every "earlier" pool is initially a copy of any later pool. But then, you don't need any "list" of pools, you just need to create new pools, such as by copying or linking with copy-on-write from an existing pool. I still think there is something to be done here however. I think the initial unshipped output should be in the same or more similar directory structure as a shipped pool/package store/repository. For the outputs -- the .so, .m3x, .m3web, .m3exports files, this seems simple and good. The fact that shipping also copies all the source files however, is a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" placed upon output, then ship would just be a recursive copy, or move, or change the root. However "ship" remains "complicated" due to the "need" to ship the sources -- or, do sources not really need to be shipped? One thing I wonder, haven't tracked down, is if sources are shipped because the compiler, i.e. import, needs them, or "only" for debugging? Maybe the .m3x files handle all the import needs, and the .i3 files are never reparsed? Still, surely the source .ig files are shipped because they might be needed. And "only" for debugging is still important. Perhaps perhaps the source should be "shipped" as part of building? You know, they have to be read anyway, so it is not a super wasteful expense. You know, imagine I am in a long edit/compile/test loop, and won't really "ship" till much later -- is it a big waste for "compile" to also copy any changed files to the output directory, even though ultimately they are all dead except for the last version? I use Reactor briefly years ago, the commercial version. I was not impressed. As I recall it claims to be an "IDE", but lacks an editor and debugger, and maybe more. As I recall it is a custom web server, that you use with any browser, and provides not much more than browsing hyperlinked source code. I will try it again soon. Not providing an editor, in retrospect, is probably smart. I was young then and would have tried whatever ideal language oriented editor it came with. Since then I have used the same editor for over 10 years and reasons to change must be /extremely/ strong. Not providing a debugger was also probably not a bad decision, given the effort and system-specific work involved, though maybe a gui wrapper over gdb would be good (e.g. Xcode). - Jay ________________________________ > Date: Mon, 6 Jul 2009 20:49:36 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiple pkg roots > > > > > > > > From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose. > > > > The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--i.e. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers. > > > > Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight. > > > > Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose. > > > > Perhaps my understanding of what is meant by "pool" needs clarification? > > > > Regards, > > Randy Coleburn From wagner at elegosoft.com Tue Jul 7 08:26:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 08:26:23 +0200 Subject: [M3devel] WDROOT private repository not working? In-Reply-To: <67172.22662.qm@web56806.mail.re3.yahoo.com> References: <67172.22662.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090707082623.ihmzdg2lw8o8kook@mail.elegosoft.com> WDROOT has no special meaning in CM3, it was just a convention used in _some_ override files. More used just ROOT, so we left it that way years ago. The m3overrides mechanism does work as expected in CM3. If you speficy the -overrides option to the compiler, it additionally reads all m3override files. In almost all overrides shipped with CM3 ROOT is used. Hope this helps, Olaf Quoting Peter Eiserloh : > > Hi Guys, > > Seeing all the attention placed on creating relative > linking, and so forth, I decided to examine the behavior > of CM3, when building for a private root. > > So, I set WDROOT to ${HOME}/m3work in my m3makefile. > > ---- BEGIN m3makefile ---- > %# Time-Space-Position Information (TSPI) library > > HOME = "/home/peter" > WDROOT = HOME & "/m3work" > > include_dir("xform") > % include_dir("smoothing") > % include_dir("editing") > % include_dir("geoid") > % include_dir("testing") > ---- EMD m3makefile ---- > > > Then I, attempted to build and ship from there. > > It said, there was an error > > ---- BEGIN ERROR MSG ---- > peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship > --- shipping from ../AMD64_LINUX --- > > "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: > quake runtime error: unable to create directory > "/usr/lib/cm3/pkg/tspi": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP > > ---- END ERROR MSG ---- > > > > Was support for WDROOT removed? Can CM3 support the ability to > have a private repository, while also having the public repo? > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Tue Jul 7 08:54:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Jul 2009 23:54:58 -0700 Subject: [M3devel] multiple pkg roots In-Reply-To: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." Message-ID: <200907070654.n676swq8048959@taps.cs.caltech.edu> Jay K writes: > >a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla >ced upon output, then ship would just be a recursive copy, or move, or change >the root. However "ship" remains "complicated" due to the "need" to ship the s >ources -- or, do sources not really need to be shipped? One thing I wonder, ha >ven't tracked down, is if sources are shipped because the compiler, i.e. impor >t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im >port needs, and the .i3 files are never reparsed? Still, surely the source .ig > files are shipped because they might be needed. And "only" for debugging is s >till important. Perhaps perhaps the source should be "shipped" as part of buil >ding? You know, they have to be read anyway, so it is not a super wasteful exp >ense. You know, imagine I am in a long edit/compile/test loop, and won't reall >y "ship" till much later -- is it a big waste for "compile" to also copy any c >hanged files to the output directory, even though ultimately they are all dead > except for the last version? Isn't the main purpose of any programming language that it is used for human-to-human communication? The .i3s need to be shipped so that programmers can see the interface of the libraries they are using, whether it be for debugging or initial development. That also means they should be shipped precisely when the binaries are shipped (they have to remain synchronized). Things would get extremely confusing if sources (I'd prefer to call them "interfaces"---you don't have to ship the "implementation modules") and binaries are shipped at different times. Mika From jay.krell at cornell.edu Tue Jul 7 09:05:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 07:05:54 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <200907070654.n676swq8048959@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." <200907070654.n676swq8048959@taps.cs.caltech.edu> Message-ID: Mostly agreed. It's just, you know, there is a contradiction between "making ship just a recursive copy or link" and "not wastefully copying files" Given that files would only be copied when they change, and when they change they have to read anyway, maybe it's not so bad. The dilemna is whether or not "build" copies the sources, so that ship is just recursive copy/link, or if build shouldn't waste time doing so and ship would continue to do all/some directory layout changes. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 6 Jul 2009 23:54:58 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] multiple pkg roots > > Jay K writes: >> >>a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla >>ced upon output, then ship would just be a recursive copy, or move, or change >>the root. However "ship" remains "complicated" due to the "need" to ship the s >>ources -- or, do sources not really need to be shipped? One thing I wonder, ha >>ven't tracked down, is if sources are shipped because the compiler, i.e. impor >>t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im >>port needs, and the .i3 files are never reparsed? Still, surely the source .ig >> files are shipped because they might be needed. And "only" for debugging is s >>till important. Perhaps perhaps the source should be "shipped" as part of buil >>ding? You know, they have to be read anyway, so it is not a super wasteful exp >>ense. You know, imagine I am in a long edit/compile/test loop, and won't reall >>y "ship" till much later -- is it a big waste for "compile" to also copy any c >>hanged files to the output directory, even though ultimately they are all dead >> except for the last version? > > Isn't the main purpose of any programming language that it is used > for human-to-human communication? > > The .i3s need to be shipped so that programmers can see the interface > of the libraries they are using, whether it be for debugging or > initial development. That also means they should be shipped precisely > when the binaries are shipped (they have to remain synchronized). > Things would get extremely confusing if sources (I'd prefer to call > them "interfaces"---you don't have to ship the "implementation > modules") and binaries are shipped at different times. > > Mika From wagner at elegosoft.com Tue Jul 7 11:28:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 11:28:15 +0200 Subject: [M3devel] multiple pkg roots In-Reply-To: References: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." <200907070654.n676swq8048959@taps.cs.caltech.edu> Message-ID: <20090707112815.hn3o411jc4kc8ow4@mail.elegosoft.com> Just some short comments from me before I leave you again for a while: o My suggestion of using multiple pools is just a generalization of the existing PKGROOT concept. It's intended to better support project and team setups in software development. There was no intention to use this to support `CM3 evolution' as Randy calls it (though it could be used for it). o I would not like to restrict the concept to two pools or levels. o For a first step, I'd suggest to keep thing really simple: - make cm3 understand a CM3_POOL_PATH to satisfy imports - only ship to the leftmost pool in the path - mark the hierarchy level in the pools (e.g. 0: system global, 1: project level, 2: individual workspace level) - disallow shipping when packages from lower pools than the one shipped to are referenced This way, there is no explicit promote operation (that can be added later), but we should be able to keep the dependencies correct easily. (I haven't thought this through completely though, so I may be mistaken.) I just realize that this might not be correct though: if a library package is locally modified and tested in a local pool, we'd probably like the other importers in the global pool to use our new dependency, too, or we'd end up with two versions of the same library in our program, which would probably neither work (names clashes) nor be what we intended: so we'd have to teach cm3 to detect those `invalid' importers and forbid us to use them. I.e. modifying a base library would require us to recompile (and probably adapt) all depending packages. It seems that all this needs more and careful consideration... o I also strongly suggest to postpone all this until we've finished the current release. Olaf Quoting Jay K : > > Mostly agreed. > It's just, you know, there is a contradiction between > "making ship just a recursive copy or link" > and > "not wastefully copying files" > > > Given that files would only be copied when they change, and when > they change they have to read anyway, maybe it's not so bad. > > > The dilemna is whether or not "build" copies the sources, so that > ship is just recursive copy/link, or if build shouldn't waste time > doing so and ship would continue to do all/some directory layout > changes. > > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon, 6 Jul 2009 23:54:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] multiple pkg roots >> >> Jay K writes: >>> >>> a wrinkle. That is, if it were just the output .so, .m3x etc., >>> "correctly" pla >>> ced upon output, then ship would just be a recursive copy, or >>> move, or change >>> the root. However "ship" remains "complicated" due to the "need" >>> to ship the s >>> ources -- or, do sources not really need to be shipped? One thing >>> I wonder, ha >>> ven't tracked down, is if sources are shipped because the >>> compiler, i.e. impor >>> t, needs them, or "only" for debugging? Maybe the .m3x files >>> handle all the im >>> port needs, and the .i3 files are never reparsed? Still, surely >>> the source .ig >>> files are shipped because they might be needed. And "only" for >>> debugging is s >>> till important. Perhaps perhaps the source should be "shipped" as >>> part of buil >>> ding? You know, they have to be read anyway, so it is not a super >>> wasteful exp >>> ense. You know, imagine I am in a long edit/compile/test loop, and >>> won't reall >>> y "ship" till much later -- is it a big waste for "compile" to >>> also copy any c >>> hanged files to the output directory, even though ultimately they >>> are all dead >>> except for the last version? >> >> Isn't the main purpose of any programming language that it is used >> for human-to-human communication? >> >> The .i3s need to be shipped so that programmers can see the interface >> of the libraries they are using, whether it be for debugging or >> initial development. That also means they should be shipped precisely >> when the binaries are shipped (they have to remain synchronized). >> Things would get extremely confusing if sources (I'd prefer to call >> them "interfaces"---you don't have to ship the "implementation >> modules") and binaries are shipped at different times. >> >> Mika -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 7 14:31:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 12:31:13 +0000 Subject: [M3devel] pkg roots/origin/ld_library_path Message-ID: Really, I understand, but there is a problem nobody seems to see. Let's say there are multiple pkg roots. Remember my question? It is very important. "How are the dependencies of an .so or executable found?" What if I install to /opt/cm3. You install to $HOME/cm3 -- no need for root! We have some root/bin/executable. It uses of course libm3core.so. I want to be able to copy it from machine to machine, probably without relinking it or running some tool over it. People want to install libm3core.so to different places on different machines. Does root/bin/executable refer to /opt/cm3/lib? or $HOME/cm3/lib? or $ORIGIN/../lib? or no directory and user sets LD_LIBRARY_PATH? I'm not even sure you can omit the directory. There is a basic contradiction here. $ORIGIN is good. $ORIGIN is bad. LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. Full paths are good. Full paths are bad. The ability to install to different places is good. The ability to install to different places is bad. You cannot have all of: ability to specify install location AND multiple package roots, where a package root is sparse AND if I install to a custom location, I don't have to set LD_LIBRARY_PATH Now, while I advocate(d) $ORIGIN and custom install locations and no need for LD_LIBRARY_PATH, that approach does devolve to everything being in the same directory, which also seems not great. The difference is often that you don't use $ORIGIN for "well known important stuff". You don't get "libc.so" from $ORIGIN/../lib. You get it from where it always is, like /usr/lib or somesuch. You don't actually ever use a custom install for it. If you want to build your own, you are probably building your own entire system, and might use chroot as part of that. But where is the line between "my stuff" and "well known important stuff"? Where is the line between stuff that can be installed anywhere vs. stuff that must be installed to its "standard" location? - Jay From wagner at elegosoft.com Tue Jul 7 15:05:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 15:05:45 +0200 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: References: Message-ID: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> I understand that the $ORIGIN use in library paths does not work if we want to have hierarchical overrides for an arbitrary set of package pools. We'll either have to use absolute paths or rely on a correct (automatically computed?) LD_LIBRARY_PATH setting. How do $ORIGIN and LD_LIBRARY_PATH work together? Are there consistently defined semantics on different systems? Could we use $ORIGIN just for the one global system installation, and rely on absolute paths for all other pools? Of course we'd loose the ability to just copy from one pool to another this way, but that may not be that important. Anyway, we (at least I) won't work on it right now... Olaf Quoting Jay K : > > Really, I understand, but there is a problem nobody seems to see. > > > Let's say there are multiple pkg roots. > > > Remember my question? It is very important. > "How are the dependencies of an .so or executable found?" > > > What if I install to /opt/cm3. > You install to $HOME/cm3 -- no need for root! > We have some root/bin/executable. > It uses of course libm3core.so. > > > I want to be able to copy it from machine to machine, probably > without relinking it or running some tool over it. > > > People want to install libm3core.so to different places on different > machines. > > > Does root/bin/executable refer > to /opt/cm3/lib? > or $HOME/cm3/lib? > or $ORIGIN/../lib? > or no directory and user sets LD_LIBRARY_PATH? > I'm not even sure you can omit the directory. > > > There is a basic contradiction here. > $ORIGIN is good. $ORIGIN is bad. > LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. > Full paths are good. Full paths are bad. > The ability to install to different places is good. The ability to > install to different places is bad. > > > You cannot have all of: > ability to specify install location > AND multiple package roots, where a package root is sparse > AND if I install to a custom location, I don't have to set LD_LIBRARY_PATH > > > Now, while I advocate(d) $ORIGIN and custom install locations and no > need for LD_LIBRARY_PATH, that approach does devolve to everything > being in the same directory, which also seems not great. > > > The difference is often that you don't use $ORIGIN for "well known > important stuff". > You don't get "libc.so" from $ORIGIN/../lib. You get it from where > it always is, like /usr/lib or somesuch. You don't actually ever use > a custom install for it. If you want to build your own, you are > probably building your own entire system, and might use chroot as > part of that. > > > But where is the line between "my stuff" and "well known important > stuff"? Where is the line between stuff that can be installed > anywhere vs. stuff that must be installed to its "standard" location? > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Tue Jul 7 22:02:53 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Jul 2009 15:02:53 -0500 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <20090703231254.GA25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> Message-ID: <4A53A9ED.8020908@cox.net> This may only be peripherally related, but since this discussion has come up: I have long wished for a directory, neither src, nor the architecture directory, for files that are mechanically generated but not target dependent. I have an application where there are several machine-generated files containing Modula-3 "source" code. It's "source code", in the sense that it is input to the compiler, but not "source code", in the sense that it is not written by a human using an editor. Some existing quake commands for instantiating generics do similarly. Neither place is entirely appropriate for these files. I have gone through a series of kludgy ways of handling this. Right now, I have them in a directory "derived", beside "src", with lines in m3makefiles that look, e.g., like: 'implementation("../derived/M3InitTokStrings")'. But the instantiating quake functions put generated source code in the arch directory, and sometimes unnecessarily regenerate it. Just something that it would be nice to clean up. hendrik at topoi.pooq.com wrote: > It seems relevant to out multiarchitecture system that Debian and Ubuntu > are currently also struggling to put together a multiarchitecture > system. > > Current thinking seems to be posted at > https://wiki.ubuntu.com/MultiarchSpec > > The stimulus for this work seems to be having 32-bit and 64-bit programs > coexist on the same AMD-64 system. But it also deals with questions > like MIPS systems having at least three different ABIs. > > Have a look. > > -- hendrik > > > From mika at async.caltech.edu Tue Jul 7 23:16:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Jul 2009 14:16:00 -0700 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> Message-ID: <200907072116.n67LG01G054470@taps.cs.caltech.edu> Going in the "other direction" it might be nice to have different derived directories for different compilers, e.g., CM3 and PM3, or different versions of CM3. Not something that is really necessary for anyone, I'm sure, but it seems like a flexible mechanism for "derived" directories might be able to handle that too... Mika "Rodney M. Bates" writes: >This may only be peripherally related, but since this discussion >has come up: > >I have long wished for a directory, neither src, nor the architecture >directory, for files that are mechanically generated but not >target dependent. I have an application where there are several >machine-generated files containing Modula-3 "source" code. > >It's "source code", in the sense that it is input to the compiler, but not >"source code", in the sense that it is not written by a human using >an editor. Some existing quake commands for instantiating generics >do similarly. Neither place is entirely appropriate for these files. > >I have gone through a series of kludgy ways of handling this. Right >now, I have them in a directory "derived", beside "src", with lines in >m3makefiles that look, e.g., like: > 'implementation("../derived/M3InitTokStrings")'. > >But the instantiating quake functions put generated source code in >the arch directory, and sometimes unnecessarily regenerate it. > >Just something that it would be nice to clean up. > >hendrik at topoi.pooq.com wrote: >> It seems relevant to out multiarchitecture system that Debian and Ubuntu >> are currently also struggling to put together a multiarchitecture >> system. >> >> Current thinking seems to be posted at >> https://wiki.ubuntu.com/MultiarchSpec >> >> The stimulus for this work seems to be having 32-bit and 64-bit programs >> coexist on the same AMD-64 system. But it also deals with questions >> like MIPS systems having at least three different ABIs. >> >> Have a look. >> >> -- hendrik >> >> >> From jay.krell at cornell.edu Tue Jul 7 23:48:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 21:48:47 +0000 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <200907072116.n67LG01G054470@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> <200907072116.n67LG01G054470@taps.cs.caltech.edu> Message-ID: Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are. The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages. So you could do export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here ./do-cm3-std.py buildship export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here ./do-cm3-std.py buildship etc. ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there. The "problem" is that compile/link don't. Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path. MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line. Then you'd just export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic. However you get stuck in the "what is the same? What is different?" dilemna. What if I want to not optimize just some particular code I am debugging? It should still go along with all the rest of the code. What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto. Probably the "hash" overridable from the command line. But you still want good defaults. I have not seen this automatic approach used much. But certainly the idea of one output root is good. Certainly the original authors were thinking this way, they just stopped way short. - Jay ---------------------------------------- > To: rodney.m.bates at cox.net > Date: Tue, 7 Jul 2009 14:16:00 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch) > > Going in the "other direction" it might be nice to have different > derived directories for different compilers, e.g., CM3 and PM3, or > different versions of CM3. > > Not something that is really necessary for anyone, I'm sure, but > it seems like a flexible mechanism for "derived" directories might > be able to handle that too... > > Mika > > "Rodney M. Bates" writes: >>This may only be peripherally related, but since this discussion >>has come up: >> >>I have long wished for a directory, neither src, nor the architecture >>directory, for files that are mechanically generated but not >>target dependent. I have an application where there are several >>machine-generated files containing Modula-3 "source" code. >> >>It's "source code", in the sense that it is input to the compiler, but not >>"source code", in the sense that it is not written by a human using >>an editor. Some existing quake commands for instantiating generics >>do similarly. Neither place is entirely appropriate for these files. >> >>I have gone through a series of kludgy ways of handling this. Right >>now, I have them in a directory "derived", beside "src", with lines in >>m3makefiles that look, e.g., like: >> 'implementation("../derived/M3InitTokStrings")'. >> >>But the instantiating quake functions put generated source code in >>the arch directory, and sometimes unnecessarily regenerate it. >> >>Just something that it would be nice to clean up. >> >>hendrik at topoi.pooq.com wrote: >>> It seems relevant to out multiarchitecture system that Debian and Ubuntu >>> are currently also struggling to put together a multiarchitecture >>> system. >>> >>> Current thinking seems to be posted at >>> https://wiki.ubuntu.com/MultiarchSpec >>> >>> The stimulus for this work seems to be having 32-bit and 64-bit programs >>> coexist on the same AMD-64 system. But it also deals with questions >>> like MIPS systems having at least three different ABIs. >>> >>> Have a look. >>> >>> -- hendrik >>> >>> >>> From jay.krell at cornell.edu Tue Jul 7 22:56:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 7 Jul 2009 13:56:05 -0700 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> Message-ID: I see the base contradiction is between custom install location, non root install, and Unix binary installs. Whenever I install binaries in Unix I have to be root and I get no choice of install location. Only when I build from source are both of these relaxed. Windows varies. Often I can chose install location and sometimes I don't have to be admin (but I always am). $origin is a way to address this, but relative locations remain fixed. - Jay (phone) On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: > I understand that the $ORIGIN use in library paths does not work > if we want to have hierarchical overrides for an arbitrary set of > package pools. We'll either have to use absolute paths or rely > on a correct (automatically computed?) LD_LIBRARY_PATH setting. > > How do $ORIGIN and LD_LIBRARY_PATH work together? Are there > consistently defined semantics on different systems? > > Could we use $ORIGIN just for the one global system installation, > and rely on absolute paths for all other pools? Of course we'd > loose the ability to just copy from one pool to another this way, > but that may not be that important. > > Anyway, we (at least I) won't work on it right now... > > Olaf > > Quoting Jay K : > >> >> Really, I understand, but there is a problem nobody seems to see. >> >> >> Let's say there are multiple pkg roots. >> >> >> Remember my question? It is very important. >> "How are the dependencies of an .so or executable found?" >> >> >> What if I install to /opt/cm3. >> You install to $HOME/cm3 -- no need for root! >> We have some root/bin/executable. >> It uses of course libm3core.so. >> >> >> I want to be able to copy it from machine to machine, probably >> without relinking it or running some tool over it. >> >> >> People want to install libm3core.so to different places on >> different machines. >> >> >> Does root/bin/executable refer >> to /opt/cm3/lib? >> or $HOME/cm3/lib? >> or $ORIGIN/../lib? >> or no directory and user sets LD_LIBRARY_PATH? >> I'm not even sure you can omit the directory. >> >> >> There is a basic contradiction here. >> $ORIGIN is good. $ORIGIN is bad. >> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >> Full paths are good. Full paths are bad. >> The ability to install to different places is good. The ability to >> install to different places is bad. >> >> >> You cannot have all of: >> ability to specify install location >> AND multiple package roots, where a package root is sparse >> AND if I install to a custom location, I don't have to set >> LD_LIBRARY_PATH >> >> >> Now, while I advocate(d) $ORIGIN and custom install locations and >> no need for LD_LIBRARY_PATH, that approach does devolve to >> everything being in the same directory, which also seems not great. >> >> >> The difference is often that you don't use $ORIGIN for "well known >> important stuff". >> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >> it always is, like /usr/lib or somesuch. You don't actually ever >> use a custom install for it. If you want to build your own, you >> are probably building your own entire system, and might use chroot >> as part of that. >> >> >> But where is the line between "my stuff" and "well known important >> stuff"? Where is the line between stuff that can be installed >> anywhere vs. stuff that must be installed to its "standard" location? >> >> >> - Jay > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Tue Jul 7 23:50:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 21:50:05 +0000 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <200907072116.n67LG01G054470@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> <200907072116.n67LG01G054470@taps.cs.caltech.edu> Message-ID: ps: ccache is something that kind of goes this automatic way, but for different reasons and not really applicable. It is looking for opportunistic identicalness and really striving for the strongest definition of identical. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; rodney.m.bates at cox.net > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Arch-independent derived files (Re: multiarch) > Date: Tue, 7 Jul 2009 21:48:47 +0000 > > > Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are. > > > The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages. > > > So you could do > > export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here > export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here > ./do-cm3-std.py buildship > > > export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here > export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here > ./do-cm3-std.py buildship > > etc. > > ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there. > > The "problem" is that compile/link don't. > > Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path. > > MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line. > > Then you'd just > export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic. > > However you get stuck in the "what is the same? What is different?" dilemna. > What if I want to not optimize just some particular code I am debugging? > It should still go along with all the rest of the code. > What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto. > > > Probably the "hash" overridable from the command line. > But you still want good defaults. > > > I have not seen this automatic approach used much. > But certainly the idea of one output root is good. > Certainly the original authors were thinking this way, they just stopped way short. > > > - Jay > > > > > > ---------------------------------------- >> To: rodney.m.bates at cox.net >> Date: Tue, 7 Jul 2009 14:16:00 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch) >> >> Going in the "other direction" it might be nice to have different >> derived directories for different compilers, e.g., CM3 and PM3, or >> different versions of CM3. >> >> Not something that is really necessary for anyone, I'm sure, but >> it seems like a flexible mechanism for "derived" directories might >> be able to handle that too... >> >> Mika >> >> "Rodney M. Bates" writes: >>>This may only be peripherally related, but since this discussion >>>has come up: >>> >>>I have long wished for a directory, neither src, nor the architecture >>>directory, for files that are mechanically generated but not >>>target dependent. I have an application where there are several >>>machine-generated files containing Modula-3 "source" code. >>> >>>It's "source code", in the sense that it is input to the compiler, but not >>>"source code", in the sense that it is not written by a human using >>>an editor. Some existing quake commands for instantiating generics >>>do similarly. Neither place is entirely appropriate for these files. >>> >>>I have gone through a series of kludgy ways of handling this. Right >>>now, I have them in a directory "derived", beside "src", with lines in >>>m3makefiles that look, e.g., like: >>> 'implementation("../derived/M3InitTokStrings")'. >>> >>>But the instantiating quake functions put generated source code in >>>the arch directory, and sometimes unnecessarily regenerate it. >>> >>>Just something that it would be nice to clean up. >>> >>>hendrik at topoi.pooq.com wrote: >>>> It seems relevant to out multiarchitecture system that Debian and Ubuntu >>>> are currently also struggling to put together a multiarchitecture >>>> system. >>>> >>>> Current thinking seems to be posted at >>>> https://wiki.ubuntu.com/MultiarchSpec >>>> >>>> The stimulus for this work seems to be having 32-bit and 64-bit programs >>>> coexist on the same AMD-64 system. But it also deals with questions >>>> like MIPS systems having at least three different ABIs. >>>> >>>> Have a look. >>>> >>>> -- hendrik >>>> >>>> >>>> From jay.krell at cornell.edu Tue Jul 7 22:38:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 7 Jul 2009 13:38:48 -0700 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <4A53A9ED.8020908@cox.net> References: <20090703231254.GA25415@topoi.pooq.com> <4A53A9ED.8020908@cox.net> Message-ID: I have seen systems head that way, only to abandon it, for the sake of consistency and simplicity -- outputs all in one more known place, and for concurrency -- build multiple architectures without them stomping on each other. Are the files large or slow to be generated? I am on the fence. I like identifying what is the same and removing duplication. But if it is automated and fast, less motivation. Considering more of the system, we do parse identical .i3 files per- platform. The middle end work is also almost the same for every platform. But judging from the overall NT386 speed, this is all very fast. - Jay (phone) On Jul 7, 2009, at 1:02 PM, "Rodney M. Bates" wrote: > This may only be peripherally related, but since this discussion > has come up: > > I have long wished for a directory, neither src, nor the architecture > directory, for files that are mechanically generated but not > target dependent. I have an application where there are several > machine-generated files containing Modula-3 "source" code. > > It's "source code", in the sense that it is input to the compiler, > but not > "source code", in the sense that it is not written by a human using > an editor. Some existing quake commands for instantiating generics > do similarly. Neither place is entirely appropriate for these files. > > I have gone through a series of kludgy ways of handling this. Right > now, I have them in a directory "derived", beside "src", with lines in > m3makefiles that look, e.g., like: > 'implementation("../derived/M3InitTokStrings")'. > > But the instantiating quake functions put generated source code in > the arch directory, and sometimes unnecessarily regenerate it. > > Just something that it would be nice to clean up. > > hendrik at topoi.pooq.com wrote: >> It seems relevant to out multiarchitecture system that Debian and >> Ubuntu are currently also struggling to put together a >> multiarchitecture system. >> >> Current thinking seems to be posted at >> https://wiki.ubuntu.com/MultiarchSpec >> >> The stimulus for this work seems to be having 32-bit and 64-bit >> programs coexist on the same AMD-64 system. But it also deals with >> questions like MIPS systems having at least three different ABIs. >> >> Have a look. >> >> -- hendrik >> >> >> > > From carson at taltos.org Fri Jul 10 01:15:51 2009 From: carson at taltos.org (Carson Gaspar) Date: Thu, 09 Jul 2009 16:15:51 -0700 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> Message-ID: <4A567A27.8080203@taltos.org> LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X) _usually_ overrides a compiled-in search path. I know it does on Linux, MacOS X, and Solaris. And yes, you can "omit the directory" on most flavours of UNIX (although not on MacOS X, which gets complicated). If you leave out rpath, only the system default locations (and LD_LIBRARY_PATH, if set) will be searched. My opinion: - The primary installation should be built using a relative RPATH only ($ORIGIN/../lib or whatever). That does imply flatening the installed namespace to something more traditional, or including symlinks (if you have /usr/local/m3/lib/libfoo.so and /usr/local/m3/my/sub/module/mybinary you'd need to symlink /usr/local/m3/my/sub/module/lib to ../../../lib, or symlink each .so.*). - If a user builds with an alternate root, it should include an absolute RPATH for the standard installed location. It may _also_ include a relative RPATH, if needed (module builds its own .so libs), which should come first. This allows: - The binary install to be moved between systems easily - Binary non-standard location modules to be moved to any location on systems that share the same standard install location. This is about as flexible as you can get on most platforms. Note that on MacOS X you can use install_name_tool to re-write library locations, as long as the original was built with enough padding (linked with -headerpad_max_install_names, or the new name is shorter). This will also be possible on newer versions of Solaris, but is not yet in Sol 10 (only in OpenSolaris). jay.krell at cornell.edu wrote: > I see the base contradiction is between custom install location, non > root install, and Unix binary installs. Whenever I install binaries in > Unix I have to be root and I get no choice of install location. Only > when I build from source are both of these relaxed. > > Windows varies. Often I can chose install location and sometimes I don't > have to be admin (but I always am). > > $origin is a way to address this, but relative locations remain fixed. > > - Jay (phone) > > On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: > >> I understand that the $ORIGIN use in library paths does not work >> if we want to have hierarchical overrides for an arbitrary set of >> package pools. We'll either have to use absolute paths or rely >> on a correct (automatically computed?) LD_LIBRARY_PATH setting. >> >> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there >> consistently defined semantics on different systems? >> >> Could we use $ORIGIN just for the one global system installation, >> and rely on absolute paths for all other pools? Of course we'd >> loose the ability to just copy from one pool to another this way, >> but that may not be that important. >> >> Anyway, we (at least I) won't work on it right now... >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Really, I understand, but there is a problem nobody seems to see. >>> >>> >>> Let's say there are multiple pkg roots. >>> >>> >>> Remember my question? It is very important. >>> "How are the dependencies of an .so or executable found?" >>> >>> >>> What if I install to /opt/cm3. >>> You install to $HOME/cm3 -- no need for root! >>> We have some root/bin/executable. >>> It uses of course libm3core.so. >>> >>> >>> I want to be able to copy it from machine to machine, probably >>> without relinking it or running some tool over it. >>> >>> >>> People want to install libm3core.so to different places on different >>> machines. >>> >>> >>> Does root/bin/executable refer >>> to /opt/cm3/lib? >>> or $HOME/cm3/lib? >>> or $ORIGIN/../lib? >>> or no directory and user sets LD_LIBRARY_PATH? >>> I'm not even sure you can omit the directory. >>> >>> >>> There is a basic contradiction here. >>> $ORIGIN is good. $ORIGIN is bad. >>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >>> Full paths are good. Full paths are bad. >>> The ability to install to different places is good. The ability to >>> install to different places is bad. >>> >>> >>> You cannot have all of: >>> ability to specify install location >>> AND multiple package roots, where a package root is sparse >>> AND if I install to a custom location, I don't have to set >>> LD_LIBRARY_PATH >>> >>> >>> Now, while I advocate(d) $ORIGIN and custom install locations and no >>> need for LD_LIBRARY_PATH, that approach does devolve to everything >>> being in the same directory, which also seems not great. >>> >>> >>> The difference is often that you don't use $ORIGIN for "well known >>> important stuff". >>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >>> it always is, like /usr/lib or somesuch. You don't actually ever use >>> a custom install for it. If you want to build your own, you are >>> probably building your own entire system, and might use chroot as >>> part of that. >>> >>> >>> But where is the line between "my stuff" and "well known important >>> stuff"? Where is the line between stuff that can be installed >>> anywhere vs. stuff that must be installed to its "standard" location? >>> >>> >>> - Jay >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 >> 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> From jay.krell at cornell.edu Fri Jul 10 03:36:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 10 Jul 2009 01:36:21 +0000 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: <4A567A27.8080203@taltos.org> References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> <4A567A27.8080203@taltos.org> Message-ID: I think we very much agree. Which comes first, LD_LIBRARY_PATH or runpath? The default build uses both $ORIGIN/../lib and fullpath. Like you suggest. I forget the order. $ORIGIN first would be good I think. I'll check and make it so. There is an environment variable to suppress the fullpath. The existing "scripts" set it. You can find its name in the scripts and the config files. Something like CM3_PORTABLE_RUNPATH. I know environment variables are lame. The structure has already been flattened. It was always "available" flattened, but symlinked into the deep structure, which I believe largely defeated our current goals. Now there is just the flat structure and the deep structure is "gone" (well, two files removed out of each directory). I also put $ORIGIN alone in the runpath, without the ../lib, so you can further flatten lib into bin. I'm fairly sympathetic to that but I suspect not many other people are. ? I always reserve the maximum space on MacOSX (in the config files), having seen that stuff in the manpages and figuring "reserving the maximum" probably isn't too wasteful and is a nice item on the "flexibility checklist" (that is, something I'll probably never use, but if anyone wants it, sure, it's there). That way, "link upon install" can be "run that tool upon install". I had seen similar for Solaris but I forget the details, which you filled in. - Jay ---------------------------------------- > Date: Thu, 9 Jul 2009 16:15:51 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] pkg roots/origin/ld_library_path > > LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X) _usually_ overrides a > compiled-in search path. I know it does on Linux, MacOS X, and Solaris. > > And yes, you can "omit the directory" on most flavours of UNIX (although not on > MacOS X, which gets complicated). If you leave out rpath, only the system > default locations (and LD_LIBRARY_PATH, if set) will be searched. > > My opinion: > > - The primary installation should be built using a relative RPATH only > ($ORIGIN/../lib or whatever). That does imply flatening the installed namespace > to something more traditional, or including symlinks (if you have > /usr/local/m3/lib/libfoo.so and /usr/local/m3/my/sub/module/mybinary you'd need > to symlink /usr/local/m3/my/sub/module/lib to ../../../lib, or symlink each .so.*). > > - If a user builds with an alternate root, it should include an absolute RPATH > for the standard installed location. It may _also_ include a relative RPATH, if > needed (module builds its own .so libs), which should come first. > > This allows: > > - The binary install to be moved between systems easily > - Binary non-standard location modules to be moved to any location on systems > that share the same standard install location. > > This is about as flexible as you can get on most platforms. > > Note that on MacOS X you can use install_name_tool to re-write library > locations, as long as the original was built with enough padding (linked with > -headerpad_max_install_names, or the new name is shorter). This will also be > possible on newer versions of Solaris, but is not yet in Sol 10 (only in > OpenSolaris). > > > jay.krell at cornell.edu wrote: >> I see the base contradiction is between custom install location, non >> root install, and Unix binary installs. Whenever I install binaries in >> Unix I have to be root and I get no choice of install location. Only >> when I build from source are both of these relaxed. >> >> Windows varies. Often I can chose install location and sometimes I don't >> have to be admin (but I always am). >> >> $origin is a way to address this, but relative locations remain fixed. >> >> - Jay (phone) >> >> On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: >> >>> I understand that the $ORIGIN use in library paths does not work >>> if we want to have hierarchical overrides for an arbitrary set of >>> package pools. We'll either have to use absolute paths or rely >>> on a correct (automatically computed?) LD_LIBRARY_PATH setting. >>> >>> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there >>> consistently defined semantics on different systems? >>> >>> Could we use $ORIGIN just for the one global system installation, >>> and rely on absolute paths for all other pools? Of course we'd >>> loose the ability to just copy from one pool to another this way, >>> but that may not be that important. >>> >>> Anyway, we (at least I) won't work on it right now... >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Really, I understand, but there is a problem nobody seems to see. >>>> >>>> >>>> Let's say there are multiple pkg roots. >>>> >>>> >>>> Remember my question? It is very important. >>>> "How are the dependencies of an .so or executable found?" >>>> >>>> >>>> What if I install to /opt/cm3. >>>> You install to $HOME/cm3 -- no need for root! >>>> We have some root/bin/executable. >>>> It uses of course libm3core.so. >>>> >>>> >>>> I want to be able to copy it from machine to machine, probably >>>> without relinking it or running some tool over it. >>>> >>>> >>>> People want to install libm3core.so to different places on different >>>> machines. >>>> >>>> >>>> Does root/bin/executable refer >>>> to /opt/cm3/lib? >>>> or $HOME/cm3/lib? >>>> or $ORIGIN/../lib? >>>> or no directory and user sets LD_LIBRARY_PATH? >>>> I'm not even sure you can omit the directory. >>>> >>>> >>>> There is a basic contradiction here. >>>> $ORIGIN is good. $ORIGIN is bad. >>>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >>>> Full paths are good. Full paths are bad. >>>> The ability to install to different places is good. The ability to >>>> install to different places is bad. >>>> >>>> >>>> You cannot have all of: >>>> ability to specify install location >>>> AND multiple package roots, where a package root is sparse >>>> AND if I install to a custom location, I don't have to set >>>> LD_LIBRARY_PATH >>>> >>>> >>>> Now, while I advocate(d) $ORIGIN and custom install locations and no >>>> need for LD_LIBRARY_PATH, that approach does devolve to everything >>>> being in the same directory, which also seems not great. >>>> >>>> >>>> The difference is often that you don't use $ORIGIN for "well known >>>> important stuff". >>>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >>>> it always is, like /usr/lib or somesuch. You don't actually ever use >>>> a custom install for it. If you want to build your own, you are >>>> probably building your own entire system, and might use chroot as >>>> part of that. >>>> >>>> >>>> But where is the line between "my stuff" and "well known important >>>> stuff"? Where is the line between stuff that can be installed >>>> anywhere vs. stuff that must be installed to its "standard" location? >>>> >>>> >>>> - Jay >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 >>> 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> > > From wagner at elegosoft.com Sat Jul 11 12:47:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Jul 2009 12:47:44 +0200 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <255528.11130.qm@web56801.mail.re3.yahoo.com> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Hm, I'm afraid we may have a regression in the runtime/gc here. CVSup always worked without problems for me (and still is copying FreeBSD, CM3 and other repositories between various machines for me and Elego). Surely CVSup is doing no such thing as keeping all its files in memory. I haven't tried the version Jay put into the CM3 repo though. So I see three possibilities: o Jay introduced the problem in the CVSup sources when he adapted them to the current CM3 (low probability). o You've got a broken runtime / CM3 version (and current sources work). I'd guess you are using the current version though. o We've got a problem in our runtime code, perhaps -- but not necessarily -- the garbage collector. I'd suggest we rule out the second one and you reproduce the problem with a current source set (if not done yet). Then let's see what Jay and Antony have to say, as they did almost all the source changes in that area recently. Olaf Quoting Peter Eiserloh : > Hi Olaf, > > Well, I tried CVSup, and it started looking real good, until > it crashed, with a message from the M3 runtime, saying that > NEW could not allocate any memory. > > So I ran it a second time, and it got further, then crashed > again. > > So, a third time, but with "top" running in another window, > and sure enough cvsup, was allocating something like 1.2 GB > of data before it was crashing. This is bigger than the > CVS repository that it had already downloaded. > > I am thinking that cvsup is keeping the contents of every > file it downloaded in memory. If so, this is a problem. > > If it is properly removing references, then maybe the > garbage collector is failing. This would be a bigger > problem, but with our compiler's runtime library. > > Are other people noticing problems. Is it just me? > Am I the only one to attempt downloading the entire > CVS repository for CM3? Could you try it? > > > I sent an email to the email listed in cvsup's "about box" > (cvsup-bugs at polstra.com), but that failed. The email address > no longer works. > > peter at black:/data/modula-3/cm3 $ > debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup cvsupfile.cm3 > > *** > *** runtime error: > *** NEW() was unable to allocate more memory. > *** file "../src/runtime/common/RuntimeError.m3", line 63 > *** > > Aborted > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Olaf Wagner wrote: > >> From: Olaf Wagner >> Subject: Re: m3gdb and YACC >> To: "Peter Eiserloh" >> Date: Saturday, July 11, 2009, 2:49 AM >> Quoting Peter Eiserloh : >> >> > Hi Olaf, >> > >> > The import script (git-importcvs) internally uses >> cvsps, which >> > you may already have. >> > >> > Anyways, here is the first ten lines from a log file >> of an import >> > that I just started. >> > >> > >> > peter at black:~ $ head Import-cm3-20090708.log >> > Running cvsps... >> > WARNING: revision 1.1.3.1 of file >> m3-sys/m3cc/gcc/etc/make-stds.texi? on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >> > WARNING: revision 1.1.3.1 of file >> m3-sys/m3cc/gcc/.brik on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >> branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >> branch >> >> It looks like these files have a second vendor branch >> without a >> proper name. CVS does not cope well with multiple vendor >> branches >> (in fact it never really worked), but there won't be any >> valuable >> information in that branch I'm sure, so you can ignore it. >> >> > Later this weekend, I will attempt to use CVSup.? >> First, >> > I will have to find usable documentation, since I >> have >> > never used CVSup before. >> > >> > Do you have a script to use with CVSup to access the >> > CM3 CVS repo?? I am lasy. >> > >> > I use 'git' for all my current projects.? I used >> to use >> > CVS, and had started looking into using subversion >> (SVN), >> > I even purchased a couple books on SVN.? Then >> 'git' burst >> > upon the Linux world, and is gaining converts all over >> the >> > place. >> > >> > It really does provide a better work-flow.? The >> easy >> > creation of a branch is a given, it is git's ability >> > to do easy merges, which is gaining all the good >> reputation. >> > >> > Rather than get all evangelistic on you, as I am sure >> you >> > have already heard it many times already. >> > >> > Many businesses are moving to git.? The only >> problem some >> > enterprise companies are having is the ability to >> restrict >> > access of authorized users to only portions of the >> repository. >> > These types of problems don't effect open source >> software >> > development. >> > >> > Once I have a working 'git' repository for cm3, I will >> share >> > the technique, and maybe, start the foundations for a >> > transition from CVS, towards 'git'.? But I >> suggest a slow >> > process, with distinct stages.???At any >> stage we could stop, >> > or even revert. >> > >> > The problem is that once people start using git, they >> don''t >> > want to go back to using CVS, or any of the older >> methods. >> > Maybe that isn't so much of a problem after all. >> > >> > STAGE-1: Simple mirror of the CVS archive, >> periodically >> >? ? ? ? ? updated (say once >> every 6 hours).? Document on >> >? ? ? ? ? web site, as to how >> to clone, and update a git >> >? ? ? ? ? repository.? No >> uploads to git. >> > STAGE-2: Convert web page scripts to use git. >> > STAGE-3: Convert tinderbox. >> > STAGE-4: Uploads to git.? Install gitosis or >> similar server >> >? ? ? ? ? for git uploads. >> Document the upload process on web >> >? ? ? ? ? pages. >> > STAGE-5: CVS mirrors the git repo.? Uploads to >> git only. >> > STAGE-6: Move last of the CVS people, over to git. >> > STAGE-7: Remove CVS.? (optional) >> >> Let's see how far you get. Converting all the >> infrastructure (scripts >> and documentation) may be much more work than you imagine. >> And one >> we propose a special tool (be it git or svn or mercurial) >> there will >> start discussions on what is best and what we should do >> :-/ >> >> So offering an optional alternative access may be a good >> plan. >> The majority of users should agree that they want the >> change though. >> And we need to consider use of GUIs and Windows users, >> too. >> >> Olaf >> --Olaf Wagner -- elego Software Solutions GmbH >> ? ? ? ? ? ? >> ???Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, Germany >> phone: +49 30 23 45 86 96? mobile: +49 177 2345 >> 869? fax: +49 30 23 45 86 95 >> ???http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 11 17:19:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 11:19:52 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: I'd definitely need some way to reproduce the problem. Detailed instructions would be best. What platform are you running on? On 11 Jul 2009, at 06:47, Olaf Wagner wrote: > Hm, I'm afraid we may have a regression in the runtime/gc here. > CVSup always worked without problems for me (and still is copying > FreeBSD, CM3 and other repositories between various machines for > me and Elego). Surely CVSup is doing no such thing as keeping > all its files in memory. > > I haven't tried the version Jay put into the CM3 repo though. > So I see three possibilities: > > o Jay introduced the problem in the CVSup sources when he > adapted them to the current CM3 (low probability). > > o You've got a broken runtime / CM3 version (and current > sources work). I'd guess you are using the current version though. > > o We've got a problem in our runtime code, perhaps -- but not > necessarily -- the garbage collector. > > I'd suggest we rule out the second one and you reproduce the problem > with a current source set (if not done yet). Then let's see what Jay > and Antony have to say, as they did almost all the source changes > in that area recently. > > Olaf > > Quoting Peter Eiserloh : > >> Hi Olaf, >> >> Well, I tried CVSup, and it started looking real good, until >> it crashed, with a message from the M3 runtime, saying that >> NEW could not allocate any memory. >> >> So I ran it a second time, and it got further, then crashed >> again. >> >> So, a third time, but with "top" running in another window, >> and sure enough cvsup, was allocating something like 1.2 GB >> of data before it was crashing. This is bigger than the >> CVS repository that it had already downloaded. >> >> I am thinking that cvsup is keeping the contents of every >> file it downloaded in memory. If so, this is a problem. >> >> If it is properly removing references, then maybe the >> garbage collector is failing. This would be a bigger >> problem, but with our compiler's runtime library. >> >> Are other people noticing problems. Is it just me? >> Am I the only one to attempt downloading the entire >> CVS repository for CM3? Could you try it? >> >> >> I sent an email to the email listed in cvsup's "about box" >> (cvsup-bugs at polstra.com), but that failed. The email address >> no longer works. >> >> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/usr/ >> lib/cm3/bin/cvsup cvsupfile.cm3 >> >> *** >> *** runtime error: >> *** NEW() was unable to allocate more memory. >> *** file "../src/runtime/common/RuntimeError.m3", line 63 >> *** >> >> Aborted >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, Olaf Wagner wrote: >> >>> From: Olaf Wagner >>> Subject: Re: m3gdb and YACC >>> To: "Peter Eiserloh" >>> Date: Saturday, July 11, 2009, 2:49 AM >>> Quoting Peter Eiserloh : >>> >>> > Hi Olaf, >>> > >>> > The import script (git-importcvs) internally uses >>> cvsps, which >>> > you may already have. >>> > >>> > Anyways, here is the first ten lines from a log file >>> of an import >>> > that I just started. >>> > >>> > >>> > peter at black:~ $ head Import-cm3-20090708.log >>> > Running cvsps... >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/.brik on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>> branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>> branch >>> >>> It looks like these files have a second vendor branch >>> without a >>> proper name. CVS does not cope well with multiple vendor >>> branches >>> (in fact it never really worked), but there won't be any >>> valuable >>> information in that branch I'm sure, so you can ignore it. >>> >>> > Later this weekend, I will attempt to use CVSup. >>> First, >>> > I will have to find usable documentation, since I >>> have >>> > never used CVSup before. >>> > >>> > Do you have a script to use with CVSup to access the >>> > CM3 CVS repo? I am lasy. >>> > >>> > I use 'git' for all my current projects. I used >>> to use >>> > CVS, and had started looking into using subversion >>> (SVN), >>> > I even purchased a couple books on SVN. Then >>> 'git' burst >>> > upon the Linux world, and is gaining converts all over >>> the >>> > place. >>> > >>> > It really does provide a better work-flow. The >>> easy >>> > creation of a branch is a given, it is git's ability >>> > to do easy merges, which is gaining all the good >>> reputation. >>> > >>> > Rather than get all evangelistic on you, as I am sure >>> you >>> > have already heard it many times already. >>> > >>> > Many businesses are moving to git. The only >>> problem some >>> > enterprise companies are having is the ability to >>> restrict >>> > access of authorized users to only portions of the >>> repository. >>> > These types of problems don't effect open source >>> software >>> > development. >>> > >>> > Once I have a working 'git' repository for cm3, I will >>> share >>> > the technique, and maybe, start the foundations for a >>> > transition from CVS, towards 'git'. But I >>> suggest a slow >>> > process, with distinct stages. At any >>> stage we could stop, >>> > or even revert. >>> > >>> > The problem is that once people start using git, they >>> don''t >>> > want to go back to using CVS, or any of the older >>> methods. >>> > Maybe that isn't so much of a problem after all. >>> > >>> > STAGE-1: Simple mirror of the CVS archive, >>> periodically >>> > updated (say once >>> every 6 hours). Document on >>> > web site, as to how >>> to clone, and update a git >>> > repository. No >>> uploads to git. >>> > STAGE-2: Convert web page scripts to use git. >>> > STAGE-3: Convert tinderbox. >>> > STAGE-4: Uploads to git. Install gitosis or >>> similar server >>> > for git uploads. >>> Document the upload process on web >>> > pages. >>> > STAGE-5: CVS mirrors the git repo. Uploads to >>> git only. >>> > STAGE-6: Move last of the CVS people, over to git. >>> > STAGE-7: Remove CVS. (optional) >>> >>> Let's see how far you get. Converting all the >>> infrastructure (scripts >>> and documentation) may be much more work than you imagine. >>> And one >>> we propose a special tool (be it git or svn or mercurial) >>> there will >>> start discussions on what is best and what we should do >>> :-/ >>> >>> So offering an optional alternative access may be a good >>> plan. >>> The majority of users should agree that they want the >>> change though. >>> And we need to consider use of GUIs and Windows users, >>> too. >>> >>> Olaf >>> --Olaf Wagner -- elego Software Solutions GmbH >>> >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>> Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>> 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | >>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>> USt-IdNr: DE163214194 >>> >>> >> >> >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 11 18:21:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 12:21:28 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: Weird. I've just noticed that the collector has been disabled in RTCollector.i3 (not sure why I did that, but it had something to do with Jay's changes to the locking code in ThreadPThread). It should definitely be reverted, but probably exposes some weirdness in Jay's mutex initialization code. Jay, can you help? On 11 Jul 2009, at 11:19, Tony Hosking wrote: > I'd definitely need some way to reproduce the problem. Detailed > instructions would be best. What platform are you running on? > > On 11 Jul 2009, at 06:47, Olaf Wagner wrote: > >> Hm, I'm afraid we may have a regression in the runtime/gc here. >> CVSup always worked without problems for me (and still is copying >> FreeBSD, CM3 and other repositories between various machines for >> me and Elego). Surely CVSup is doing no such thing as keeping >> all its files in memory. >> >> I haven't tried the version Jay put into the CM3 repo though. >> So I see three possibilities: >> >> o Jay introduced the problem in the CVSup sources when he >> adapted them to the current CM3 (low probability). >> >> o You've got a broken runtime / CM3 version (and current >> sources work). I'd guess you are using the current version though. >> >> o We've got a problem in our runtime code, perhaps -- but not >> necessarily -- the garbage collector. >> >> I'd suggest we rule out the second one and you reproduce the problem >> with a current source set (if not done yet). Then let's see what Jay >> and Antony have to say, as they did almost all the source changes >> in that area recently. >> >> Olaf >> >> Quoting Peter Eiserloh : >> >>> Hi Olaf, >>> >>> Well, I tried CVSup, and it started looking real good, until >>> it crashed, with a message from the M3 runtime, saying that >>> NEW could not allocate any memory. >>> >>> So I ran it a second time, and it got further, then crashed >>> again. >>> >>> So, a third time, but with "top" running in another window, >>> and sure enough cvsup, was allocating something like 1.2 GB >>> of data before it was crashing. This is bigger than the >>> CVS repository that it had already downloaded. >>> >>> I am thinking that cvsup is keeping the contents of every >>> file it downloaded in memory. If so, this is a problem. >>> >>> If it is properly removing references, then maybe the >>> garbage collector is failing. This would be a bigger >>> problem, but with our compiler's runtime library. >>> >>> Are other people noticing problems. Is it just me? >>> Am I the only one to attempt downloading the entire >>> CVS repository for CM3? Could you try it? >>> >>> >>> I sent an email to the email listed in cvsup's "about box" >>> (cvsup-bugs at polstra.com), but that failed. The email address >>> no longer works. >>> >>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>> >>> *** >>> *** runtime error: >>> *** NEW() was unable to allocate more memory. >>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>> *** >>> >>> Aborted >>> >>> Peter >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>> >>>> From: Olaf Wagner >>>> Subject: Re: m3gdb and YACC >>>> To: "Peter Eiserloh" >>>> Date: Saturday, July 11, 2009, 2:49 AM >>>> Quoting Peter Eiserloh : >>>> >>>> > Hi Olaf, >>>> > >>>> > The import script (git-importcvs) internally uses >>>> cvsps, which >>>> > you may already have. >>>> > >>>> > Anyways, here is the first ten lines from a log file >>>> of an import >>>> > that I just started. >>>> > >>>> > >>>> > peter at black:~ $ head Import-cm3-20090708.log >>>> > Running cvsps... >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>> branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>> branch >>>> >>>> It looks like these files have a second vendor branch >>>> without a >>>> proper name. CVS does not cope well with multiple vendor >>>> branches >>>> (in fact it never really worked), but there won't be any >>>> valuable >>>> information in that branch I'm sure, so you can ignore it. >>>> >>>> > Later this weekend, I will attempt to use CVSup. >>>> First, >>>> > I will have to find usable documentation, since I >>>> have >>>> > never used CVSup before. >>>> > >>>> > Do you have a script to use with CVSup to access the >>>> > CM3 CVS repo? I am lasy. >>>> > >>>> > I use 'git' for all my current projects. I used >>>> to use >>>> > CVS, and had started looking into using subversion >>>> (SVN), >>>> > I even purchased a couple books on SVN. Then >>>> 'git' burst >>>> > upon the Linux world, and is gaining converts all over >>>> the >>>> > place. >>>> > >>>> > It really does provide a better work-flow. The >>>> easy >>>> > creation of a branch is a given, it is git's ability >>>> > to do easy merges, which is gaining all the good >>>> reputation. >>>> > >>>> > Rather than get all evangelistic on you, as I am sure >>>> you >>>> > have already heard it many times already. >>>> > >>>> > Many businesses are moving to git. The only >>>> problem some >>>> > enterprise companies are having is the ability to >>>> restrict >>>> > access of authorized users to only portions of the >>>> repository. >>>> > These types of problems don't effect open source >>>> software >>>> > development. >>>> > >>>> > Once I have a working 'git' repository for cm3, I will >>>> share >>>> > the technique, and maybe, start the foundations for a >>>> > transition from CVS, towards 'git'. But I >>>> suggest a slow >>>> > process, with distinct stages. At any >>>> stage we could stop, >>>> > or even revert. >>>> > >>>> > The problem is that once people start using git, they >>>> don''t >>>> > want to go back to using CVS, or any of the older >>>> methods. >>>> > Maybe that isn't so much of a problem after all. >>>> > >>>> > STAGE-1: Simple mirror of the CVS archive, >>>> periodically >>>> > updated (say once >>>> every 6 hours). Document on >>>> > web site, as to how >>>> to clone, and update a git >>>> > repository. No >>>> uploads to git. >>>> > STAGE-2: Convert web page scripts to use git. >>>> > STAGE-3: Convert tinderbox. >>>> > STAGE-4: Uploads to git. Install gitosis or >>>> similar server >>>> > for git uploads. >>>> Document the upload process on web >>>> > pages. >>>> > STAGE-5: CVS mirrors the git repo. Uploads to >>>> git only. >>>> > STAGE-6: Move last of the CVS people, over to git. >>>> > STAGE-7: Remove CVS. (optional) >>>> >>>> Let's see how far you get. Converting all the >>>> infrastructure (scripts >>>> and documentation) may be much more work than you imagine. >>>> And one >>>> we propose a special tool (be it git or svn or mercurial) >>>> there will >>>> start discussions on what is best and what we should do >>>> :-/ >>>> >>>> So offering an optional alternative access may be a good >>>> plan. >>>> The majority of users should agree that they want the >>>> change though. >>>> And we need to consider use of GUIs and Windows users, >>>> too. >>>> >>>> Olaf >>>> --Olaf Wagner -- elego Software Solutions GmbH >>>> >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>> Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>> 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>> >>> >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 11 19:12:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 13:12:19 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> Not sure how it happened, but the collector was turned off by default. It works for me now with the latest updates. On 11 Jul 2009, at 12:21, Tony Hosking wrote: > Weird. I've just noticed that the collector has been disabled in > RTCollector.i3 (not sure why I did that, but it had something to do > with Jay's changes to the locking code in ThreadPThread). It should > definitely be reverted, but probably exposes some weirdness in Jay's > mutex initialization code. Jay, can you help? > > > On 11 Jul 2009, at 11:19, Tony Hosking wrote: > >> I'd definitely need some way to reproduce the problem. Detailed >> instructions would be best. What platform are you running on? >> >> On 11 Jul 2009, at 06:47, Olaf Wagner wrote: >> >>> Hm, I'm afraid we may have a regression in the runtime/gc here. >>> CVSup always worked without problems for me (and still is copying >>> FreeBSD, CM3 and other repositories between various machines for >>> me and Elego). Surely CVSup is doing no such thing as keeping >>> all its files in memory. >>> >>> I haven't tried the version Jay put into the CM3 repo though. >>> So I see three possibilities: >>> >>> o Jay introduced the problem in the CVSup sources when he >>> adapted them to the current CM3 (low probability). >>> >>> o You've got a broken runtime / CM3 version (and current >>> sources work). I'd guess you are using the current version though. >>> >>> o We've got a problem in our runtime code, perhaps -- but not >>> necessarily -- the garbage collector. >>> >>> I'd suggest we rule out the second one and you reproduce the problem >>> with a current source set (if not done yet). Then let's see what Jay >>> and Antony have to say, as they did almost all the source changes >>> in that area recently. >>> >>> Olaf >>> >>> Quoting Peter Eiserloh : >>> >>>> Hi Olaf, >>>> >>>> Well, I tried CVSup, and it started looking real good, until >>>> it crashed, with a message from the M3 runtime, saying that >>>> NEW could not allocate any memory. >>>> >>>> So I ran it a second time, and it got further, then crashed >>>> again. >>>> >>>> So, a third time, but with "top" running in another window, >>>> and sure enough cvsup, was allocating something like 1.2 GB >>>> of data before it was crashing. This is bigger than the >>>> CVS repository that it had already downloaded. >>>> >>>> I am thinking that cvsup is keeping the contents of every >>>> file it downloaded in memory. If so, this is a problem. >>>> >>>> If it is properly removing references, then maybe the >>>> garbage collector is failing. This would be a bigger >>>> problem, but with our compiler's runtime library. >>>> >>>> Are other people noticing problems. Is it just me? >>>> Am I the only one to attempt downloading the entire >>>> CVS repository for CM3? Could you try it? >>>> >>>> >>>> I sent an email to the email listed in cvsup's "about box" >>>> (cvsup-bugs at polstra.com), but that failed. The email address >>>> no longer works. >>>> >>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>>> >>>> *** >>>> *** runtime error: >>>> *** NEW() was unable to allocate more memory. >>>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>>> *** >>>> >>>> Aborted >>>> >>>> Peter >>>> >>>> >>>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh | >>>> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>>> >>>>> From: Olaf Wagner >>>>> Subject: Re: m3gdb and YACC >>>>> To: "Peter Eiserloh" >>>>> Date: Saturday, July 11, 2009, 2:49 AM >>>>> Quoting Peter Eiserloh : >>>>> >>>>> > Hi Olaf, >>>>> > >>>>> > The import script (git-importcvs) internally uses >>>>> cvsps, which >>>>> > you may already have. >>>>> > >>>>> > Anyways, here is the first ten lines from a log file >>>>> of an import >>>>> > that I just started. >>>>> > >>>>> > >>>>> > peter at black:~ $ head Import-cm3-20090708.log >>>>> > Running cvsps... >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>>> branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>>> branch >>>>> >>>>> It looks like these files have a second vendor branch >>>>> without a >>>>> proper name. CVS does not cope well with multiple vendor >>>>> branches >>>>> (in fact it never really worked), but there won't be any >>>>> valuable >>>>> information in that branch I'm sure, so you can ignore it. >>>>> >>>>> > Later this weekend, I will attempt to use CVSup. >>>>> First, >>>>> > I will have to find usable documentation, since I >>>>> have >>>>> > never used CVSup before. >>>>> > >>>>> > Do you have a script to use with CVSup to access the >>>>> > CM3 CVS repo? I am lasy. >>>>> > >>>>> > I use 'git' for all my current projects. I used >>>>> to use >>>>> > CVS, and had started looking into using subversion >>>>> (SVN), >>>>> > I even purchased a couple books on SVN. Then >>>>> 'git' burst >>>>> > upon the Linux world, and is gaining converts all over >>>>> the >>>>> > place. >>>>> > >>>>> > It really does provide a better work-flow. The >>>>> easy >>>>> > creation of a branch is a given, it is git's ability >>>>> > to do easy merges, which is gaining all the good >>>>> reputation. >>>>> > >>>>> > Rather than get all evangelistic on you, as I am sure >>>>> you >>>>> > have already heard it many times already. >>>>> > >>>>> > Many businesses are moving to git. The only >>>>> problem some >>>>> > enterprise companies are having is the ability to >>>>> restrict >>>>> > access of authorized users to only portions of the >>>>> repository. >>>>> > These types of problems don't effect open source >>>>> software >>>>> > development. >>>>> > >>>>> > Once I have a working 'git' repository for cm3, I will >>>>> share >>>>> > the technique, and maybe, start the foundations for a >>>>> > transition from CVS, towards 'git'. But I >>>>> suggest a slow >>>>> > process, with distinct stages. At any >>>>> stage we could stop, >>>>> > or even revert. >>>>> > >>>>> > The problem is that once people start using git, they >>>>> don''t >>>>> > want to go back to using CVS, or any of the older >>>>> methods. >>>>> > Maybe that isn't so much of a problem after all. >>>>> > >>>>> > STAGE-1: Simple mirror of the CVS archive, >>>>> periodically >>>>> > updated (say once >>>>> every 6 hours). Document on >>>>> > web site, as to how >>>>> to clone, and update a git >>>>> > repository. No >>>>> uploads to git. >>>>> > STAGE-2: Convert web page scripts to use git. >>>>> > STAGE-3: Convert tinderbox. >>>>> > STAGE-4: Uploads to git. Install gitosis or >>>>> similar server >>>>> > for git uploads. >>>>> Document the upload process on web >>>>> > pages. >>>>> > STAGE-5: CVS mirrors the git repo. Uploads to >>>>> git only. >>>>> > STAGE-6: Move last of the CVS people, over to git. >>>>> > STAGE-7: Remove CVS. (optional) >>>>> >>>>> Let's see how far you get. Converting all the >>>>> infrastructure (scripts >>>>> and documentation) may be much more work than you imagine. >>>>> And one >>>>> we propose a special tool (be it git or svn or mercurial) >>>>> there will >>>>> start discussions on what is best and what we should do >>>>> :-/ >>>>> >>>>> So offering an optional alternative access may be a good >>>>> plan. >>>>> The majority of users should agree that they want the >>>>> change though. >>>>> And we need to consider use of GUIs and Windows users, >>>>> too. >>>>> >>>>> Olaf >>>>> --Olaf Wagner -- elego Software Solutions GmbH >>>>> >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>>> Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>>> 869 fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | >>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sat Jul 11 22:10:29 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 11 Jul 2009 13:10:29 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <756206.45056.qm@web56807.mail.re3.yahoo.com> Hi Tony, Architecture: AMD64_LINUX. Code base: 20090628. I am untarring 20090710 right now, and will rebuild the CM3 against it using the standard scripts/do-cm3-std.sh I don't expect any difference in behavior though as that is pretty much what my Makefile does anyways. Okay, I can also try this on my old Macintosh (PPC_DARWIN). Are there any additional diagnostics that I can turn on in the runtime? Something simple may help like when NEW complains, printing out: o the size of memory currently allocated, o the current number of allocations, o the total number of allocations performed, o the number of garbage collection runs performed, and o the number of objects reclaimed by the garbage collector, and so forth. This may be difficult since we just failed to allocate, memory, the diagnostics may not have the ability to format strings for output. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 7/11/09, Tony Hosking wrote: > From: Tony Hosking > Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC > To: "Olaf Wagner" > Cc: "Peter Eiserloh" , m3devel at elegosoft.com > Date: Saturday, July 11, 2009, 8:19 AM > I'd definitely need some way to reproduce the > problem. ?Detailed instructions would be best. > ?What platform are you running > on? > On 11 Jul 2009, at 06:47, Olaf > Wagner > wrote: > Hm, I'm afraid we may have a regression > in the runtime/gc here. > CVSup always worked without problems for me (and still is > copying > FreeBSD, CM3 and other repositories between various > machines for > me and Elego). Surely CVSup is doing no such thing as > keeping > all its files in memory. > > I haven't tried the version Jay put into the CM3 repo > though. > So I see three possibilities: > > o Jay introduced the problem in the CVSup sources when he > ??adapted them to the current CM3 (low > probability). > > o You've got a broken runtime / CM3 version (and > current > ??sources work). I'd guess you are using the > current version though. > > o We've got a problem in our runtime code, perhaps -- > but not > ??necessarily -- the garbage collector. > > I'd suggest we rule out the second one and you > reproduce the problem > with a current source set (if not done yet). Then let's > see what Jay > and Antony have to say, as they did almost all the source > changes > in that area recently. > > Olaf > > Quoting Peter Eiserloh : > > Hi Olaf, > > Well, I tried CVSup, > and it started looking real good, until > it crashed, with a > message from the M3 runtime, saying that > NEW could not allocate > any memory. > > So I ran it a second > time, and it got further, then crashed > again. > > So, a third time, but > with "top" running in another window, > and sure enough cvsup, > was allocating something like 1.2 GB > of data before it was > crashing. ?This is bigger than the > CVS repository that it > had already downloaded. > > I am thinking that > cvsup is keeping the contents of every > file it downloaded in > memory. ?If so, this is a problem. > > If it is properly > removing references, then maybe the > garbage collector is > failing. ?This would be a bigger > problem, but with our > compiler's runtime library. > > Are other people > noticing problems. ?Is it just me? > Am I the only one to > attempt downloading the entire > CVS repository for > CM3? ?Could you try it? > > > I sent an email to the > email listed in cvsup's "about box" > (cvsup-bugs at polstra.com), > but that failed. ?The email address > no longer works. > > peter at black:/data/modula-3/cm3 $ > ?debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup > cvsupfile.cm3 > > *** > *** runtime error: > *** > ???NEW() was unable to allocate more memory. > *** > ???file > "../src/runtime/common/RuntimeError.m3", line 63 > *** > > Aborted > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > ?????????????????????????????????????| > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, > Olaf Wagner > wrote: > > From: Olaf Wagner > Subject: Re: m3gdb and > YACC > To: "Peter > Eiserloh" > Date: Saturday, July 11, > 2009, 2:49 AM > Quoting Peter Eiserloh > : > > > Hi Olaf, > > > > The import script > (git-importcvs) internally uses > cvsps, which > > you may already > have. > > > > Anyways, here is > the first ten lines from a log file > of an import > > that I just > started. > > > > > > peter at black:~ $ > head Import-cm3-20090708.log > > Running cvsps... > > WARNING: revision > 1.1.3.1 of file > m3-sys/m3cc/gcc/etc/make-stds.texi? on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on > unnamed branch > > WARNING: revision > 1.1.3.1 of file > m3-sys/m3cc/gcc/.brik on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on > unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on > unnamed > branch > > It looks like these > files have a second vendor branch > without a > proper name. CVS does > not cope well with multiple vendor > branches > (in fact it never really > worked), but there won't be any > valuable > information in that > branch I'm sure, so you can ignore it. > > > Later this weekend, > I will attempt to use CVSup.? > First, > > I will have to find > usable documentation, since I > have > > never used CVSup > before. > > > > Do you have a > script to use with CVSup to access the > > CM3 CVS repo?? > I am lasy. > > > > I use 'git' > for all my current projects.? I used > to use > > CVS, and had > started looking into using subversion > (SVN), > > I even purchased a > couple books on SVN.? Then > 'git' burst > > upon the Linux > world, and is gaining converts all over > the > > place. > > > > It really does > provide a better work-flow.? The > easy > > creation of a > branch is a given, it is git's ability > > to do easy merges, > which is gaining all the good > reputation. > > > > Rather than get all > evangelistic on you, as I am sure > you > > have already heard > it many times already. > > > > Many businesses are > moving to git.? The only > problem some > > enterprise > companies are having is the ability to > restrict > > access of > authorized users to only portions of the > repository. > > These types of > problems don't effect open source > software > > development. > > > > Once I have a > working 'git' repository for cm3, I will > share > > the technique, and > maybe, start the foundations for a > > transition from > CVS, towards 'git'.? But I > suggest a slow > > process, with > distinct stages.???At any > stage we could stop, > > or even revert. > > > > The problem is that > once people start using git, they > don''t > > want to go back to > using CVS, or any of the older > methods. > > Maybe that > isn't so much of a problem after all. > > > > STAGE-1: Simple > mirror of the CVS archive, > periodically > >? ? ? > ? ? updated (say once > every 6 hours).? > Document on > >? ? ? > ? ? web site, as to how > to clone, and update a > git > >? ? ? > ? ? repository.? No > uploads to git. > > STAGE-2: Convert > web page scripts to use git. > > STAGE-3: Convert > tinderbox. > > STAGE-4: Uploads to > git.? Install gitosis or > similar server > >? ? ? > ? ? for git uploads. > Document the upload > process on web > >? ? ? > ? ? pages. > > STAGE-5: CVS > mirrors the git repo.? Uploads to > git only. > > STAGE-6: Move last > of the CVS people, over to git. > > STAGE-7: Remove > CVS.? (optional) > > Let's see how far > you get. Converting all the > infrastructure (scripts > and documentation) may > be much more work than you imagine. > And one > we propose a special > tool (be it git or svn or mercurial) > there will > start discussions on > what is best and what we should do > :-/ > > So offering an optional > alternative access may be a good > plan. > The majority of users > should agree that they want the > change though. > And we need to consider > use of GUIs and Windows users, > too. > > Olaf > --Olaf Wagner -- elego > Software Solutions GmbH > ? ? ? > ? ? ? > ???Gustav-Meyer-Allee 25 / > Geb?ude 12, 13355 > Berlin, Germany > phone: +49 30 23 45 86 > 96? mobile: +49 177 2345 > 869? fax: +49 30 23 > 45 86 95 > ???http://www.elegosoft.com > | > Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > Handelregister: > Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > > ??????????????Gustav-Meyer-Allee > 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 ?mobile: +49 177 2345 869 > ?fax: +49 30 23 45 86 95 > ??http://www.elegosoft.com > | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > From wagner at elegosoft.com Sat Jul 11 23:16:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Jul 2009 23:16:51 +0200 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> Message-ID: <20090711231651.tvmtsb7s0004g0kk@mail.elegosoft.com> Quoting Tony Hosking : > Not sure how it happened, but the collector was turned off by default. > It works for me now with the latest updates. Great, thanks for the quick check and help. I assume this will resolve Peter's problems... Olaf > On 11 Jul 2009, at 12:21, Tony Hosking wrote: > >> Weird. I've just noticed that the collector has been disabled in >> RTCollector.i3 (not sure why I did that, but it had something to do >> with Jay's changes to the locking code in ThreadPThread). It >> should definitely be reverted, but probably exposes some weirdness >> in Jay's mutex initialization code. Jay, can you help? >> >> >> On 11 Jul 2009, at 11:19, Tony Hosking wrote: >> >>> I'd definitely need some way to reproduce the problem. Detailed >>> instructions would be best. What platform are you running on? >>> >>> On 11 Jul 2009, at 06:47, Olaf Wagner wrote: >>> >>>> Hm, I'm afraid we may have a regression in the runtime/gc here. >>>> CVSup always worked without problems for me (and still is copying >>>> FreeBSD, CM3 and other repositories between various machines for >>>> me and Elego). Surely CVSup is doing no such thing as keeping >>>> all its files in memory. >>>> >>>> I haven't tried the version Jay put into the CM3 repo though. >>>> So I see three possibilities: >>>> >>>> o Jay introduced the problem in the CVSup sources when he >>>> adapted them to the current CM3 (low probability). >>>> >>>> o You've got a broken runtime / CM3 version (and current >>>> sources work). I'd guess you are using the current version though. >>>> >>>> o We've got a problem in our runtime code, perhaps -- but not >>>> necessarily -- the garbage collector. >>>> >>>> I'd suggest we rule out the second one and you reproduce the problem >>>> with a current source set (if not done yet). Then let's see what Jay >>>> and Antony have to say, as they did almost all the source changes >>>> in that area recently. >>>> >>>> Olaf >>>> >>>> Quoting Peter Eiserloh : >>>> >>>>> Hi Olaf, >>>>> >>>>> Well, I tried CVSup, and it started looking real good, until >>>>> it crashed, with a message from the M3 runtime, saying that >>>>> NEW could not allocate any memory. >>>>> >>>>> So I ran it a second time, and it got further, then crashed >>>>> again. >>>>> >>>>> So, a third time, but with "top" running in another window, >>>>> and sure enough cvsup, was allocating something like 1.2 GB >>>>> of data before it was crashing. This is bigger than the >>>>> CVS repository that it had already downloaded. >>>>> >>>>> I am thinking that cvsup is keeping the contents of every >>>>> file it downloaded in memory. If so, this is a problem. >>>>> >>>>> If it is properly removing references, then maybe the >>>>> garbage collector is failing. This would be a bigger >>>>> problem, but with our compiler's runtime library. >>>>> >>>>> Are other people noticing problems. Is it just me? >>>>> Am I the only one to attempt downloading the entire >>>>> CVS repository for CM3? Could you try it? >>>>> >>>>> >>>>> I sent an email to the email listed in cvsup's "about box" >>>>> (cvsup-bugs at polstra.com), but that failed. The email address >>>>> no longer works. >>>>> >>>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** NEW() was unable to allocate more memory. >>>>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>>>> *** >>>>> >>>>> Aborted >>>>> >>>>> Peter >>>>> >>>>> >>>>> +--------------------------------------------------------+ >>>>> | Peter P. Eiserloh | >>>>> +--------------------------------------------------------+ >>>>> >>>>> >>>>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>>>> >>>>>> From: Olaf Wagner >>>>>> Subject: Re: m3gdb and YACC >>>>>> To: "Peter Eiserloh" >>>>>> Date: Saturday, July 11, 2009, 2:49 AM >>>>>> Quoting Peter Eiserloh : >>>>>> >>>>>>> Hi Olaf, >>>>>>> >>>>>>> The import script (git-importcvs) internally uses >>>>>> cvsps, which >>>>>>> you may already have. >>>>>>> >>>>>>> Anyways, here is the first ten lines from a log file >>>>>> of an import >>>>>>> that I just started. >>>>>>> >>>>>>> >>>>>>> peter at black:~ $ head Import-cm3-20090708.log >>>>>>> Running cvsps... >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>>>> branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>>>> branch >>>>>> >>>>>> It looks like these files have a second vendor branch >>>>>> without a >>>>>> proper name. CVS does not cope well with multiple vendor >>>>>> branches >>>>>> (in fact it never really worked), but there won't be any >>>>>> valuable >>>>>> information in that branch I'm sure, so you can ignore it. >>>>>> >>>>>>> Later this weekend, I will attempt to use CVSup. >>>>>> First, >>>>>>> I will have to find usable documentation, since I >>>>>> have >>>>>>> never used CVSup before. >>>>>>> >>>>>>> Do you have a script to use with CVSup to access the >>>>>>> CM3 CVS repo? I am lasy. >>>>>>> >>>>>>> I use 'git' for all my current projects. I used >>>>>> to use >>>>>>> CVS, and had started looking into using subversion >>>>>> (SVN), >>>>>>> I even purchased a couple books on SVN. Then >>>>>> 'git' burst >>>>>>> upon the Linux world, and is gaining converts all over >>>>>> the >>>>>>> place. >>>>>>> >>>>>>> It really does provide a better work-flow. The >>>>>> easy >>>>>>> creation of a branch is a given, it is git's ability >>>>>>> to do easy merges, which is gaining all the good >>>>>> reputation. >>>>>>> >>>>>>> Rather than get all evangelistic on you, as I am sure >>>>>> you >>>>>>> have already heard it many times already. >>>>>>> >>>>>>> Many businesses are moving to git. The only >>>>>> problem some >>>>>>> enterprise companies are having is the ability to >>>>>> restrict >>>>>>> access of authorized users to only portions of the >>>>>> repository. >>>>>>> These types of problems don't effect open source >>>>>> software >>>>>>> development. >>>>>>> >>>>>>> Once I have a working 'git' repository for cm3, I will >>>>>> share >>>>>>> the technique, and maybe, start the foundations for a >>>>>>> transition from CVS, towards 'git'. But I >>>>>> suggest a slow >>>>>>> process, with distinct stages. At any >>>>>> stage we could stop, >>>>>>> or even revert. >>>>>>> >>>>>>> The problem is that once people start using git, they >>>>>> don''t >>>>>>> want to go back to using CVS, or any of the older >>>>>> methods. >>>>>>> Maybe that isn't so much of a problem after all. >>>>>>> >>>>>>> STAGE-1: Simple mirror of the CVS archive, >>>>>> periodically >>>>>>> updated (say once >>>>>> every 6 hours). Document on >>>>>>> web site, as to how >>>>>> to clone, and update a git >>>>>>> repository. No >>>>>> uploads to git. >>>>>>> STAGE-2: Convert web page scripts to use git. >>>>>>> STAGE-3: Convert tinderbox. >>>>>>> STAGE-4: Uploads to git. Install gitosis or >>>>>> similar server >>>>>>> for git uploads. >>>>>> Document the upload process on web >>>>>>> pages. >>>>>>> STAGE-5: CVS mirrors the git repo. Uploads to >>>>>> git only. >>>>>>> STAGE-6: Move last of the CVS people, over to git. >>>>>>> STAGE-7: Remove CVS. (optional) >>>>>> >>>>>> Let's see how far you get. Converting all the >>>>>> infrastructure (scripts >>>>>> and documentation) may be much more work than you imagine. >>>>>> And one >>>>>> we propose a special tool (be it git or svn or mercurial) >>>>>> there will >>>>>> start discussions on what is best and what we should do >>>>>> :-/ >>>>>> >>>>>> So offering an optional alternative access may be a good >>>>>> plan. >>>>>> The majority of users should agree that they want the >>>>>> change though. >>>>>> And we need to consider use of GUIs and Windows users, >>>>>> too. >>>>>> >>>>>> Olaf >>>>>> --Olaf Wagner -- elego Software Solutions GmbH >>>>>> >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>>>> Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>>>> 869 fax: +49 30 23 45 86 95 >>>>>> http://www.elegosoft.com | >>>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>>>> USt-IdNr: DE163214194 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>> 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 11 23:31:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 17:31:54 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <756206.45056.qm@web56807.mail.re3.yahoo.com> References: <756206.45056.qm@web56807.mail.re3.yahoo.com> Message-ID: <74B566D0-7F39-44B4-BE95-2A743DAB639F@cs.purdue.edu> Please try my recent commits from earlier to day. On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: > > Hi Tony, > > Architecture: AMD64_LINUX. > Code base: 20090628. > > I am untarring 20090710 right now, and will rebuild the > CM3 against it using the standard scripts/do-cm3-std.sh > > I don't expect any difference in behavior though as that > is pretty much what my Makefile does anyways. > > Okay, I can also try this on my old Macintosh (PPC_DARWIN). > > > Are there any additional diagnostics that I can turn on > in the runtime? Something simple may help like when NEW > complains, printing out: > o the size of memory currently allocated, > o the current number of allocations, > o the total number of allocations performed, > o the number of garbage collection runs performed, and > o the number of objects reclaimed by the garbage collector, > and so forth. > > This may be difficult since we just failed to allocate, > memory, the diagnostics may not have the ability to > format strings for output. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Tony Hosking wrote: > >> From: Tony Hosking >> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >> To: "Olaf Wagner" >> Cc: "Peter Eiserloh" , m3devel at elegosoft.com >> Date: Saturday, July 11, 2009, 8:19 AM >> I'd definitely need some way to reproduce the >> problem. Detailed instructions would be best. >> What platform are you running >> on? >> On 11 Jul 2009, at 06:47, Olaf >> Wagner >> wrote: >> Hm, I'm afraid we may have a regression >> in the runtime/gc here. >> CVSup always worked without problems for me (and still is >> copying >> FreeBSD, CM3 and other repositories between various >> machines for >> me and Elego). Surely CVSup is doing no such thing as >> keeping >> all its files in memory. >> >> I haven't tried the version Jay put into the CM3 repo >> though. >> So I see three possibilities: >> >> o Jay introduced the problem in the CVSup sources when he >> adapted them to the current CM3 (low >> probability). >> >> o You've got a broken runtime / CM3 version (and >> current >> sources work). I'd guess you are using the >> current version though. >> >> o We've got a problem in our runtime code, perhaps -- >> but not >> necessarily -- the garbage collector. >> >> I'd suggest we rule out the second one and you >> reproduce the problem >> with a current source set (if not done yet). Then let's >> see what Jay >> and Antony have to say, as they did almost all the source >> changes >> in that area recently. >> >> Olaf >> >> Quoting Peter Eiserloh : >> >> Hi Olaf, >> >> Well, I tried CVSup, >> and it started looking real good, until >> it crashed, with a >> message from the M3 runtime, saying that >> NEW could not allocate >> any memory. >> >> So I ran it a second >> time, and it got further, then crashed >> again. >> >> So, a third time, but >> with "top" running in another window, >> and sure enough cvsup, >> was allocating something like 1.2 GB >> of data before it was >> crashing. This is bigger than the >> CVS repository that it >> had already downloaded. >> >> I am thinking that >> cvsup is keeping the contents of every >> file it downloaded in >> memory. If so, this is a problem. >> >> If it is properly >> removing references, then maybe the >> garbage collector is >> failing. This would be a bigger >> problem, but with our >> compiler's runtime library. >> >> Are other people >> noticing problems. Is it just me? >> Am I the only one to >> attempt downloading the entire >> CVS repository for >> CM3? Could you try it? >> >> >> I sent an email to the >> email listed in cvsup's "about box" >> (cvsup-bugs at polstra.com), >> but that failed. The email address >> no longer works. >> >> peter at black:/data/modula-3/cm3 $ >> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >> cvsupfile.cm3 >> >> *** >> *** runtime error: >> *** >> NEW() was unable to allocate more memory. >> *** >> file >> "../src/runtime/common/RuntimeError.m3", line 63 >> *** >> >> Aborted >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh >> | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, >> Olaf Wagner >> wrote: >> >> From: Olaf Wagner >> Subject: Re: m3gdb and >> YACC >> To: "Peter >> Eiserloh" >> Date: Saturday, July 11, >> 2009, 2:49 AM >> Quoting Peter Eiserloh >> : >> >>> Hi Olaf, >>> >>> The import script >> (git-importcvs) internally uses >> cvsps, which >>> you may already >> have. >>> >>> Anyways, here is >> the first ten lines from a log file >> of an import >>> that I just >> started. >>> >>> >>> peter at black:~ $ >> head Import-cm3-20090708.log >>> Running cvsps... >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/etc/make-stds.texi on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/.brik on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >> unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >> unnamed >> branch >> >> It looks like these >> files have a second vendor branch >> without a >> proper name. CVS does >> not cope well with multiple vendor >> branches >> (in fact it never really >> worked), but there won't be any >> valuable >> information in that >> branch I'm sure, so you can ignore it. >> >>> Later this weekend, >> I will attempt to use CVSup. >> First, >>> I will have to find >> usable documentation, since I >> have >>> never used CVSup >> before. >>> >>> Do you have a >> script to use with CVSup to access the >>> CM3 CVS repo? >> I am lasy. >>> >>> I use 'git' >> for all my current projects. I used >> to use >>> CVS, and had >> started looking into using subversion >> (SVN), >>> I even purchased a >> couple books on SVN. Then >> 'git' burst >>> upon the Linux >> world, and is gaining converts all over >> the >>> place. >>> >>> It really does >> provide a better work-flow. The >> easy >>> creation of a >> branch is a given, it is git's ability >>> to do easy merges, >> which is gaining all the good >> reputation. >>> >>> Rather than get all >> evangelistic on you, as I am sure >> you >>> have already heard >> it many times already. >>> >>> Many businesses are >> moving to git. The only >> problem some >>> enterprise >> companies are having is the ability to >> restrict >>> access of >> authorized users to only portions of the >> repository. >>> These types of >> problems don't effect open source >> software >>> development. >>> >>> Once I have a >> working 'git' repository for cm3, I will >> share >>> the technique, and >> maybe, start the foundations for a >>> transition from >> CVS, towards 'git'. But I >> suggest a slow >>> process, with >> distinct stages. At any >> stage we could stop, >>> or even revert. >>> >>> The problem is that >> once people start using git, they >> don''t >>> want to go back to >> using CVS, or any of the older >> methods. >>> Maybe that >> isn't so much of a problem after all. >>> >>> STAGE-1: Simple >> mirror of the CVS archive, >> periodically >>> >> updated (say once >> every 6 hours). >> Document on >>> >> web site, as to how >> to clone, and update a >> git >>> >> repository. No >> uploads to git. >>> STAGE-2: Convert >> web page scripts to use git. >>> STAGE-3: Convert >> tinderbox. >>> STAGE-4: Uploads to >> git. Install gitosis or >> similar server >>> >> for git uploads. >> Document the upload >> process on web >>> >> pages. >>> STAGE-5: CVS >> mirrors the git repo. Uploads to >> git only. >>> STAGE-6: Move last >> of the CVS people, over to git. >>> STAGE-7: Remove >> CVS. (optional) >> >> Let's see how far >> you get. Converting all the >> infrastructure (scripts >> and documentation) may >> be much more work than you imagine. >> And one >> we propose a special >> tool (be it git or svn or mercurial) >> there will >> start discussions on >> what is best and what we should do >> :-/ >> >> So offering an optional >> alternative access may be a good >> plan. >> The majority of users >> should agree that they want the >> change though. >> And we need to consider >> use of GUIs and Windows users, >> too. >> >> Olaf >> --Olaf Wagner -- elego >> Software Solutions GmbH >> >> >> Gustav-Meyer-Allee 25 / >> Geb?ude 12, 13355 >> Berlin, Germany >> phone: +49 30 23 45 86 >> 96 mobile: +49 177 2345 >> 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com >> | >> Gesch?ftsf?hrer: Olaf >> Wagner | Sitz: Berlin >> Handelregister: >> Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> >> >> >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> >> Gustav-Meyer-Allee >> 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 >> fax: +49 30 23 45 86 95 >> http://www.elegosoft.com >> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> >> > > > From eiserlohpp at yahoo.com Sun Jul 12 20:26:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 12 Jul 2009 11:26:12 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <195840.65922.qm@web56808.mail.re3.yahoo.com> Hi Tony, Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz right now. In the mean time, I wish to report that CVSup on PPC_DARWIN built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, did run to completion. Top indicated that over 2 GB of virtual memory was being used, and over 700 MB of resident memory (ie, RAM). CVSup, used most of my CPU, making any other process (such as Finder) very difficult from which to work. Maybe we should "nice" it, or recommend is be run with "nice". Oh, well one thing at a time. BTW: The "about" box, found by clicking on the little "i" icon in the lower right corner is woefully out of date (eg. I had tried to report bugs to cvsup-bugs at polstra.org, but the email failed to get delivered). The copyright is also listed as 2003, six years ago. The reference to cvsup.org does work however. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 7/11/09, Tony Hosking wrote: > From: Tony Hosking > Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC > To: "Peter Eiserloh" > Cc: "Olaf Wagner" , m3devel at elegosoft.com > Date: Saturday, July 11, 2009, 2:31 PM > Please try my recent commits from > earlier to day. > > On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: > > > > > Hi Tony, > > > > Architecture: AMD64_LINUX. > > Code base: 20090628. > > > > I am untarring 20090710 right now, and will rebuild > the > > CM3 against it using the standard > scripts/do-cm3-std.sh > > > > I don't expect any difference in behavior though as > that > > is pretty much what my Makefile does anyways. > > > > Okay, I can also try this on my old Macintosh > (PPC_DARWIN). > > > > > > Are there any additional diagnostics that I can turn > on > > in the runtime?? Something simple may help like > when NEW > > complains, printing out: > >? o the size of memory currently allocated, > >? o the current number of allocations, > >? o the total number of allocations performed, > >? o the number of garbage collection runs > performed, and > >? o the number of objects reclaimed by the garbage > collector, > > and so forth. > > > > This may be difficult since we just failed to > allocate, > > memory, the diagnostics may not have the ability to > > format strings for output. > > > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? | > > > +--------------------------------------------------------+ > > > > > > --- On Sat, 7/11/09, Tony Hosking > wrote: > > > >> From: Tony Hosking > >> Subject: Re: [M3devel] CVSup crashing WAS: Re: > m3gdb and YACC > >> To: "Olaf Wagner" > >> Cc: "Peter Eiserloh" , > m3devel at elegosoft.com > >> Date: Saturday, July 11, 2009, 8:19 AM > >> I'd definitely need some way to reproduce the > >> problem.? Detailed instructions would be > best. > >>? What platform are you running > >> on? > >> On 11 Jul 2009, at 06:47, Olaf > >> Wagner > >> wrote: > >> Hm, I'm afraid we may have a regression > >> in the runtime/gc here. > >> CVSup always worked without problems for me (and > still is > >> copying > >> FreeBSD, CM3 and other repositories between > various > >> machines for > >> me and Elego). Surely CVSup is doing no such thing > as > >> keeping > >> all its files in memory. > >> > >> I haven't tried the version Jay put into the CM3 > repo > >> though. > >> So I see three possibilities: > >> > >> o Jay introduced the problem in the CVSup sources > when he > >>???adapted them to the current CM3 > (low > >> probability). > >> > >> o You've got a broken runtime / CM3 version (and > >> current > >>???sources work). I'd guess you are > using the > >> current version though. > >> > >> o We've got a problem in our runtime code, perhaps > -- > >> but not > >>???necessarily -- the garbage > collector. > >> > >> I'd suggest we rule out the second one and you > >> reproduce the problem > >> with a current source set (if not done yet). Then > let's > >> see what Jay > >> and Antony have to say, as they did almost all the > source > >> changes > >> in that area recently. > >> > >> Olaf > >> > >> Quoting Peter Eiserloh : > >> > >> Hi Olaf, > >> > >> Well, I tried CVSup, > >> and it started looking real good, until > >> it crashed, with a > >> message from the M3 runtime, saying that > >> NEW could not allocate > >> any memory. > >> > >> So I ran it a second > >> time, and it got further, then crashed > >> again. > >> > >> So, a third time, but > >> with "top" running in another window, > >> and sure enough cvsup, > >> was allocating something like 1.2 GB > >> of data before it was > >> crashing.? This is bigger than the > >> CVS repository that it > >> had already downloaded. > >> > >> I am thinking that > >> cvsup is keeping the contents of every > >> file it downloaded in > >> memory.? If so, this is a problem. > >> > >> If it is properly > >> removing references, then maybe the > >> garbage collector is > >> failing.? This would be a bigger > >> problem, but with our > >> compiler's runtime library. > >> > >> Are other people > >> noticing problems.? Is it just me? > >> Am I the only one to > >> attempt downloading the entire > >> CVS repository for > >> CM3?? Could you try it? > >> > >> > >> I sent an email to the > >> email listed in cvsup's "about box" > >> (cvsup-bugs at polstra.com), > >> but that failed.? The email address > >> no longer works. > >> > >> peter at black:/data/modula-3/cm3 $ > >>? > debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup > >> cvsupfile.cm3 > >> > >> *** > >> *** runtime error: > >> *** > >>? ? NEW() was unable to allocate more > memory. > >> *** > >>? ? file > >> "../src/runtime/common/RuntimeError.m3", line 63 > >> *** > >> > >> Aborted > >> > >> Peter > >> > >> > >> > +--------------------------------------------------------+ > >> | Peter P. Eiserloh > >>? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? | > >> > +--------------------------------------------------------+ > >> > >> > >> --- On Sat, 7/11/09, > >> Olaf Wagner > >> wrote: > >> > >> From: Olaf Wagner > >> Subject: Re: m3gdb and > >> YACC > >> To: "Peter > >> Eiserloh" > >> Date: Saturday, July 11, > >> 2009, 2:49 AM > >> Quoting Peter Eiserloh > >> : > >> > >>> Hi Olaf, > >>> > >>> The import script > >> (git-importcvs) internally uses > >> cvsps, which > >>> you may already > >> have. > >>> > >>> Anyways, here is > >> the first ten lines from a log file > >> of an import > >>> that I just > >> started. > >>> > >>> > >>> peter at black:~ $ > >> head Import-cm3-20090708.log > >>> Running cvsps... > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/etc/make-stds.texi? on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/.brik on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on > >> unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on > >> unnamed > >> branch > >> > >> It looks like these > >> files have a second vendor branch > >> without a > >> proper name. CVS does > >> not cope well with multiple vendor > >> branches > >> (in fact it never really > >> worked), but there won't be any > >> valuable > >> information in that > >> branch I'm sure, so you can ignore it. > >> > >>> Later this weekend, > >> I will attempt to use CVSup. > >> First, > >>> I will have to find > >> usable documentation, since I > >> have > >>> never used CVSup > >> before. > >>> > >>> Do you have a > >> script to use with CVSup to access the > >>> CM3 CVS repo? > >> I am lasy. > >>> > >>> I use 'git' > >> for all my current projects.? I used > >> to use > >>> CVS, and had > >> started looking into using subversion > >> (SVN), > >>> I even purchased a > >> couple books on SVN.? Then > >> 'git' burst > >>> upon the Linux > >> world, and is gaining converts all over > >> the > >>> place. > >>> > >>> It really does > >> provide a better work-flow.? The > >> easy > >>> creation of a > >> branch is a given, it is git's ability > >>> to do easy merges, > >> which is gaining all the good > >> reputation. > >>> > >>> Rather than get all > >> evangelistic on you, as I am sure > >> you > >>> have already heard > >> it many times already. > >>> > >>> Many businesses are > >> moving to git.? The only > >> problem some > >>> enterprise > >> companies are having is the ability to > >> restrict > >>> access of > >> authorized users to only portions of the > >> repository. > >>> These types of > >> problems don't effect open source > >> software > >>> development. > >>> > >>> Once I have a > >> working 'git' repository for cm3, I will > >> share > >>> the technique, and > >> maybe, start the foundations for a > >>> transition from > >> CVS, towards 'git'.? But I > >> suggest a slow > >>> process, with > >> distinct stages.???At any > >> stage we could stop, > >>> or even revert. > >>> > >>> The problem is that > >> once people start using git, they > >> don''t > >>> want to go back to > >> using CVS, or any of the older > >> methods. > >>> Maybe that > >> isn't so much of a problem after all. > >>> > >>> STAGE-1: Simple > >> mirror of the CVS archive, > >> periodically > >>> > >>? ???updated (say once > >> every 6 hours). > >> Document on > >>> > >>? ???web site, as to how > >> to clone, and update a > >> git > >>> > >>? ???repository.? No > >> uploads to git. > >>> STAGE-2: Convert > >> web page scripts to use git. > >>> STAGE-3: Convert > >> tinderbox. > >>> STAGE-4: Uploads to > >> git.? Install gitosis or > >> similar server > >>> > >>? ???for git uploads. > >> Document the upload > >> process on web > >>> > >>? ???pages. > >>> STAGE-5: CVS > >> mirrors the git repo.? Uploads to > >> git only. > >>> STAGE-6: Move last > >> of the CVS people, over to git. > >>> STAGE-7: Remove > >> CVS.? (optional) > >> > >> Let's see how far > >> you get. Converting all the > >> infrastructure (scripts > >> and documentation) may > >> be much more work than you imagine. > >> And one > >> we propose a special > >> tool (be it git or svn or mercurial) > >> there will > >> start discussions on > >> what is best and what we should do > >> :-/ > >> > >> So offering an optional > >> alternative access may be a good > >> plan. > >> The majority of users > >> should agree that they want the > >> change though. > >> And we need to consider > >> use of GUIs and Windows users, > >> too. > >> > >> Olaf > >> --Olaf Wagner -- elego > >> Software Solutions GmbH > >> > >> > >>? ? Gustav-Meyer-Allee 25 / > >> Geb?ude 12, 13355 > >> Berlin, Germany > >> phone: +49 30 23 45 86 > >> 96? mobile: +49 177 2345 > >> 869? fax: +49 30 23 > >> 45 86 95 > >>? ? http://www.elegosoft.com > >> | > >> Gesch?ftsf?hrer: Olaf > >> Wagner | Sitz: Berlin > >> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | > >> USt-IdNr: DE163214194 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Olaf Wagner -- elego Software Solutions GmbH > >> > >>? ? ? ? ? ? > ???Gustav-Meyer-Allee > >> 25 / Geb?ude 12, 13355 Berlin, Germany > >> phone: +49 30 23 45 86 96? mobile: +49 177 > 2345 869 > >>? fax: +49 30 23 45 86 95 > >>???http://www.elegosoft.com > >> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > >> Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > >> USt-IdNr: DE163214194 > >> > >> > >> > > > > > > > > From hosking at cs.purdue.edu Sun Jul 12 21:17:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Jul 2009 15:17:34 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <195840.65922.qm@web56808.mail.re3.yahoo.com> References: <195840.65922.qm@web56808.mail.re3.yahoo.com> Message-ID: You should find the footprint much smaller now. I'm interested to find out what it turns out to be. On 12 Jul 2009, at 14:26, Peter Eiserloh wrote: > > Hi Tony, > > Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz > right now. > > In the mean time, I wish to report that CVSup on PPC_DARWIN > built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, > did run to completion. Top indicated that over 2 GB of > virtual memory was being used, and over 700 MB of resident > memory (ie, RAM). > > CVSup, used most of my CPU, making any other process (such > as Finder) very difficult from which to work. Maybe we should > "nice" it, or recommend is be run with "nice". Oh, well > one thing at a time. > > BTW: The "about" box, found by clicking on the little "i" icon > in the lower right corner is woefully out of date (eg. I had > tried to report bugs to cvsup-bugs at polstra.org, but the email > failed to get delivered). The copyright is also listed as 2003, > six years ago. > > The reference to cvsup.org does work however. > > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Tony Hosking wrote: > >> From: Tony Hosking >> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >> To: "Peter Eiserloh" >> Cc: "Olaf Wagner" , m3devel at elegosoft.com >> Date: Saturday, July 11, 2009, 2:31 PM >> Please try my recent commits from >> earlier to day. >> >> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: >> >>> >>> Hi Tony, >>> >>> Architecture: AMD64_LINUX. >>> Code base: 20090628. >>> >>> I am untarring 20090710 right now, and will rebuild >> the >>> CM3 against it using the standard >> scripts/do-cm3-std.sh >>> >>> I don't expect any difference in behavior though as >> that >>> is pretty much what my Makefile does anyways. >>> >>> Okay, I can also try this on my old Macintosh >> (PPC_DARWIN). >>> >>> >>> Are there any additional diagnostics that I can turn >> on >>> in the runtime? Something simple may help like >> when NEW >>> complains, printing out: >>> o the size of memory currently allocated, >>> o the current number of allocations, >>> o the total number of allocations performed, >>> o the number of garbage collection runs >> performed, and >>> o the number of objects reclaimed by the garbage >> collector, >>> and so forth. >>> >>> This may be difficult since we just failed to >> allocate, >>> memory, the diagnostics may not have the ability to >>> format strings for output. >>> >>> >>> >> +--------------------------------------------------------+ >>> | Peter P. Eiserloh >> >> | >>> >> +--------------------------------------------------------+ >>> >>> >>> --- On Sat, 7/11/09, Tony Hosking >> wrote: >>> >>>> From: Tony Hosking >>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: >> m3gdb and YACC >>>> To: "Olaf Wagner" >>>> Cc: "Peter Eiserloh" , >> m3devel at elegosoft.com >>>> Date: Saturday, July 11, 2009, 8:19 AM >>>> I'd definitely need some way to reproduce the >>>> problem. Detailed instructions would be >> best. >>>> What platform are you running >>>> on? >>>> On 11 Jul 2009, at 06:47, Olaf >>>> Wagner >>>> wrote: >>>> Hm, I'm afraid we may have a regression >>>> in the runtime/gc here. >>>> CVSup always worked without problems for me (and >> still is >>>> copying >>>> FreeBSD, CM3 and other repositories between >> various >>>> machines for >>>> me and Elego). Surely CVSup is doing no such thing >> as >>>> keeping >>>> all its files in memory. >>>> >>>> I haven't tried the version Jay put into the CM3 >> repo >>>> though. >>>> So I see three possibilities: >>>> >>>> o Jay introduced the problem in the CVSup sources >> when he >>>> adapted them to the current CM3 >> (low >>>> probability). >>>> >>>> o You've got a broken runtime / CM3 version (and >>>> current >>>> sources work). I'd guess you are >> using the >>>> current version though. >>>> >>>> o We've got a problem in our runtime code, perhaps >> -- >>>> but not >>>> necessarily -- the garbage >> collector. >>>> >>>> I'd suggest we rule out the second one and you >>>> reproduce the problem >>>> with a current source set (if not done yet). Then >> let's >>>> see what Jay >>>> and Antony have to say, as they did almost all the >> source >>>> changes >>>> in that area recently. >>>> >>>> Olaf >>>> >>>> Quoting Peter Eiserloh : >>>> >>>> Hi Olaf, >>>> >>>> Well, I tried CVSup, >>>> and it started looking real good, until >>>> it crashed, with a >>>> message from the M3 runtime, saying that >>>> NEW could not allocate >>>> any memory. >>>> >>>> So I ran it a second >>>> time, and it got further, then crashed >>>> again. >>>> >>>> So, a third time, but >>>> with "top" running in another window, >>>> and sure enough cvsup, >>>> was allocating something like 1.2 GB >>>> of data before it was >>>> crashing. This is bigger than the >>>> CVS repository that it >>>> had already downloaded. >>>> >>>> I am thinking that >>>> cvsup is keeping the contents of every >>>> file it downloaded in >>>> memory. If so, this is a problem. >>>> >>>> If it is properly >>>> removing references, then maybe the >>>> garbage collector is >>>> failing. This would be a bigger >>>> problem, but with our >>>> compiler's runtime library. >>>> >>>> Are other people >>>> noticing problems. Is it just me? >>>> Am I the only one to >>>> attempt downloading the entire >>>> CVS repository for >>>> CM3? Could you try it? >>>> >>>> >>>> I sent an email to the >>>> email listed in cvsup's "about box" >>>> (cvsup-bugs at polstra.com), >>>> but that failed. The email address >>>> no longer works. >>>> >>>> peter at black:/data/modula-3/cm3 $ >>>> >> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >>>> cvsupfile.cm3 >>>> >>>> *** >>>> *** runtime error: >>>> *** >>>> NEW() was unable to allocate more >> memory. >>>> *** >>>> file >>>> "../src/runtime/common/RuntimeError.m3", line 63 >>>> *** >>>> >>>> Aborted >>>> >>>> Peter >>>> >>>> >>>> >> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh >>>> >> >> | >>>> >> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, >>>> Olaf Wagner >>>> wrote: >>>> >>>> From: Olaf Wagner >>>> Subject: Re: m3gdb and >>>> YACC >>>> To: "Peter >>>> Eiserloh" >>>> Date: Saturday, July 11, >>>> 2009, 2:49 AM >>>> Quoting Peter Eiserloh >>>> : >>>> >>>>> Hi Olaf, >>>>> >>>>> The import script >>>> (git-importcvs) internally uses >>>> cvsps, which >>>>> you may already >>>> have. >>>>> >>>>> Anyways, here is >>>> the first ten lines from a log file >>>> of an import >>>>> that I just >>>> started. >>>>> >>>>> >>>>> peter at black:~ $ >>>> head Import-cm3-20090708.log >>>>> Running cvsps... >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/etc/make-stds.texi on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/.brik on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >>>> unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >>>> unnamed >>>> branch >>>> >>>> It looks like these >>>> files have a second vendor branch >>>> without a >>>> proper name. CVS does >>>> not cope well with multiple vendor >>>> branches >>>> (in fact it never really >>>> worked), but there won't be any >>>> valuable >>>> information in that >>>> branch I'm sure, so you can ignore it. >>>> >>>>> Later this weekend, >>>> I will attempt to use CVSup. >>>> First, >>>>> I will have to find >>>> usable documentation, since I >>>> have >>>>> never used CVSup >>>> before. >>>>> >>>>> Do you have a >>>> script to use with CVSup to access the >>>>> CM3 CVS repo? >>>> I am lasy. >>>>> >>>>> I use 'git' >>>> for all my current projects. I used >>>> to use >>>>> CVS, and had >>>> started looking into using subversion >>>> (SVN), >>>>> I even purchased a >>>> couple books on SVN. Then >>>> 'git' burst >>>>> upon the Linux >>>> world, and is gaining converts all over >>>> the >>>>> place. >>>>> >>>>> It really does >>>> provide a better work-flow. The >>>> easy >>>>> creation of a >>>> branch is a given, it is git's ability >>>>> to do easy merges, >>>> which is gaining all the good >>>> reputation. >>>>> >>>>> Rather than get all >>>> evangelistic on you, as I am sure >>>> you >>>>> have already heard >>>> it many times already. >>>>> >>>>> Many businesses are >>>> moving to git. The only >>>> problem some >>>>> enterprise >>>> companies are having is the ability to >>>> restrict >>>>> access of >>>> authorized users to only portions of the >>>> repository. >>>>> These types of >>>> problems don't effect open source >>>> software >>>>> development. >>>>> >>>>> Once I have a >>>> working 'git' repository for cm3, I will >>>> share >>>>> the technique, and >>>> maybe, start the foundations for a >>>>> transition from >>>> CVS, towards 'git'. But I >>>> suggest a slow >>>>> process, with >>>> distinct stages. At any >>>> stage we could stop, >>>>> or even revert. >>>>> >>>>> The problem is that >>>> once people start using git, they >>>> don''t >>>>> want to go back to >>>> using CVS, or any of the older >>>> methods. >>>>> Maybe that >>>> isn't so much of a problem after all. >>>>> >>>>> STAGE-1: Simple >>>> mirror of the CVS archive, >>>> periodically >>>>> >>>> updated (say once >>>> every 6 hours). >>>> Document on >>>>> >>>> web site, as to how >>>> to clone, and update a >>>> git >>>>> >>>> repository. No >>>> uploads to git. >>>>> STAGE-2: Convert >>>> web page scripts to use git. >>>>> STAGE-3: Convert >>>> tinderbox. >>>>> STAGE-4: Uploads to >>>> git. Install gitosis or >>>> similar server >>>>> >>>> for git uploads. >>>> Document the upload >>>> process on web >>>>> >>>> pages. >>>>> STAGE-5: CVS >>>> mirrors the git repo. Uploads to >>>> git only. >>>>> STAGE-6: Move last >>>> of the CVS people, over to git. >>>>> STAGE-7: Remove >>>> CVS. (optional) >>>> >>>> Let's see how far >>>> you get. Converting all the >>>> infrastructure (scripts >>>> and documentation) may >>>> be much more work than you imagine. >>>> And one >>>> we propose a special >>>> tool (be it git or svn or mercurial) >>>> there will >>>> start discussions on >>>> what is best and what we should do >>>> :-/ >>>> >>>> So offering an optional >>>> alternative access may be a good >>>> plan. >>>> The majority of users >>>> should agree that they want the >>>> change though. >>>> And we need to consider >>>> use of GUIs and Windows users, >>>> too. >>>> >>>> Olaf >>>> --Olaf Wagner -- elego >>>> Software Solutions GmbH >>>> >>>> >>>> Gustav-Meyer-Allee 25 / >>>> Geb?ude 12, 13355 >>>> Berlin, Germany >>>> phone: +49 30 23 45 86 >>>> 96 mobile: +49 177 2345 >>>> 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com >>>> | >>>> Gesch?ftsf?hrer: Olaf >>>> Wagner | Sitz: Berlin >>>> Handelregister: >>>> Amtsgericht Charlottenburg HRB 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> >>>> >> Gustav-Meyer-Allee >>>> 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 869 >>>> fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com >>>> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>>> >>> >>> >>> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 13 04:55:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Jul 2009 02:55:14 +0000 Subject: [M3devel] dynamic linking broken Message-ID: It looks like I might have broken dynamic linking, when I moved .so/.dylib files only to lib and not in pkg. At least on AMD64_DARWIN we get link commands like -L /cm3/pkg/m3core -lm3core but that directory only has libm3core.a. I'll investigate further and fix. Two likely fixes: 1 Change cm3 to point -L always just at /cm3/lib instead of /cm3/pkg. 2 symlink pkg out to lib - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 13 08:53:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 12 Jul 2009 23:53:28 -0700 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <195840.65922.qm@web56808.mail.re3.yahoo.com> Message-ID: <14943A9D-777A-45BE-A993-0289C24209CC@hotmail.com> Am I off the hook? Mika you often test user mode threads right? :) Starting with gc off isn't obviously definitely wrong, could be it gets enabled once initialization is further along. Or not. - Jay (phone) On Jul 12, 2009, at 12:17 PM, Tony Hosking wrote: > You should find the footprint much smaller now. I'm interested to > find out what it turns out to be. > > On 12 Jul 2009, at 14:26, Peter Eiserloh wrote: > >> >> Hi Tony, >> >> Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz >> right now. >> >> In the mean time, I wish to report that CVSup on PPC_DARWIN >> built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, >> did run to completion. Top indicated that over 2 GB of >> virtual memory was being used, and over 700 MB of resident >> memory (ie, RAM). >> >> CVSup, used most of my CPU, making any other process (such >> as Finder) very difficult from which to work. Maybe we should >> "nice" it, or recommend is be run with "nice". Oh, well >> one thing at a time. >> >> BTW: The "about" box, found by clicking on the little "i" icon >> in the lower right corner is woefully out of date (eg. I had >> tried to report bugs to cvsup-bugs at polstra.org, but the email >> failed to get delivered). The copyright is also listed as 2003, >> six years ago. >> >> The reference to cvsup.org does work however. >> >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, Tony Hosking wrote: >> >>> From: Tony Hosking >>> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >>> To: "Peter Eiserloh" >>> Cc: "Olaf Wagner" , m3devel at elegosoft.com >>> Date: Saturday, July 11, 2009, 2:31 PM >>> Please try my recent commits from >>> earlier to day. >>> >>> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: >>> >>>> >>>> Hi Tony, >>>> >>>> Architecture: AMD64_LINUX. >>>> Code base: 20090628. >>>> >>>> I am untarring 20090710 right now, and will rebuild >>> the >>>> CM3 against it using the standard >>> scripts/do-cm3-std.sh >>>> >>>> I don't expect any difference in behavior though as >>> that >>>> is pretty much what my Makefile does anyways. >>>> >>>> Okay, I can also try this on my old Macintosh >>> (PPC_DARWIN). >>>> >>>> >>>> Are there any additional diagnostics that I can turn >>> on >>>> in the runtime? Something simple may help like >>> when NEW >>>> complains, printing out: >>>> o the size of memory currently allocated, >>>> o the current number of allocations, >>>> o the total number of allocations performed, >>>> o the number of garbage collection runs >>> performed, and >>>> o the number of objects reclaimed by the garbage >>> collector, >>>> and so forth. >>>> >>>> This may be difficult since we just failed to >>> allocate, >>>> memory, the diagnostics may not have the ability to >>>> format strings for output. >>>> >>>> >>>> >>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh >>> >>> | >>>> >>> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, Tony Hosking >>> wrote: >>>> >>>>> From: Tony Hosking >>>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: >>> m3gdb and YACC >>>>> To: "Olaf Wagner" >>>>> Cc: "Peter Eiserloh" , >>> m3devel at elegosoft.com >>>>> Date: Saturday, July 11, 2009, 8:19 AM >>>>> I'd definitely need some way to reproduce the >>>>> problem. Detailed instructions would be >>> best. >>>>> What platform are you running >>>>> on? >>>>> On 11 Jul 2009, at 06:47, Olaf >>>>> Wagner >>>>> wrote: >>>>> Hm, I'm afraid we may have a regression >>>>> in the runtime/gc here. >>>>> CVSup always worked without problems for me (and >>> still is >>>>> copying >>>>> FreeBSD, CM3 and other repositories between >>> various >>>>> machines for >>>>> me and Elego). Surely CVSup is doing no such thing >>> as >>>>> keeping >>>>> all its files in memory. >>>>> >>>>> I haven't tried the version Jay put into the CM3 >>> repo >>>>> though. >>>>> So I see three possibilities: >>>>> >>>>> o Jay introduced the problem in the CVSup sources >>> when he >>>>> adapted them to the current CM3 >>> (low >>>>> probability). >>>>> >>>>> o You've got a broken runtime / CM3 version (and >>>>> current >>>>> sources work). I'd guess you are >>> using the >>>>> current version though. >>>>> >>>>> o We've got a problem in our runtime code, perhaps >>> -- >>>>> but not >>>>> necessarily -- the garbage >>> collector. >>>>> >>>>> I'd suggest we rule out the second one and you >>>>> reproduce the problem >>>>> with a current source set (if not done yet). Then >>> let's >>>>> see what Jay >>>>> and Antony have to say, as they did almost all the >>> source >>>>> changes >>>>> in that area recently. >>>>> >>>>> Olaf >>>>> >>>>> Quoting Peter Eiserloh : >>>>> >>>>> Hi Olaf, >>>>> >>>>> Well, I tried CVSup, >>>>> and it started looking real good, until >>>>> it crashed, with a >>>>> message from the M3 runtime, saying that >>>>> NEW could not allocate >>>>> any memory. >>>>> >>>>> So I ran it a second >>>>> time, and it got further, then crashed >>>>> again. >>>>> >>>>> So, a third time, but >>>>> with "top" running in another window, >>>>> and sure enough cvsup, >>>>> was allocating something like 1.2 GB >>>>> of data before it was >>>>> crashing. This is bigger than the >>>>> CVS repository that it >>>>> had already downloaded. >>>>> >>>>> I am thinking that >>>>> cvsup is keeping the contents of every >>>>> file it downloaded in >>>>> memory. If so, this is a problem. >>>>> >>>>> If it is properly >>>>> removing references, then maybe the >>>>> garbage collector is >>>>> failing. This would be a bigger >>>>> problem, but with our >>>>> compiler's runtime library. >>>>> >>>>> Are other people >>>>> noticing problems. Is it just me? >>>>> Am I the only one to >>>>> attempt downloading the entire >>>>> CVS repository for >>>>> CM3? Could you try it? >>>>> >>>>> >>>>> I sent an email to the >>>>> email listed in cvsup's "about box" >>>>> (cvsup-bugs at polstra.com), >>>>> but that failed. The email address >>>>> no longer works. >>>>> >>>>> peter at black:/data/modula-3/cm3 $ >>>>> >>> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >>>>> cvsupfile.cm3 >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** >>>>> NEW() was unable to allocate more >>> memory. >>>>> *** >>>>> file >>>>> "../src/runtime/common/RuntimeError.m3", line 63 >>>>> *** >>>>> >>>>> Aborted >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>> +--------------------------------------------------------+ >>>>> | Peter P. Eiserloh >>>>> >>> >>> | >>>>> >>> +--------------------------------------------------------+ >>>>> >>>>> >>>>> --- On Sat, 7/11/09, >>>>> Olaf Wagner >>>>> wrote: >>>>> >>>>> From: Olaf Wagner >>>>> Subject: Re: m3gdb and >>>>> YACC >>>>> To: "Peter >>>>> Eiserloh" >>>>> Date: Saturday, July 11, >>>>> 2009, 2:49 AM >>>>> Quoting Peter Eiserloh >>>>> : >>>>> >>>>>> Hi Olaf, >>>>>> >>>>>> The import script >>>>> (git-importcvs) internally uses >>>>> cvsps, which >>>>>> you may already >>>>> have. >>>>>> >>>>>> Anyways, here is >>>>> the first ten lines from a log file >>>>> of an import >>>>>> that I just >>>>> started. >>>>>> >>>>>> >>>>>> peter at black:~ $ >>>>> head Import-cm3-20090708.log >>>>>> Running cvsps... >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/.brik on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >>>>> unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >>>>> unnamed >>>>> branch >>>>> >>>>> It looks like these >>>>> files have a second vendor branch >>>>> without a >>>>> proper name. CVS does >>>>> not cope well with multiple vendor >>>>> branches >>>>> (in fact it never really >>>>> worked), but there won't be any >>>>> valuable >>>>> information in that >>>>> branch I'm sure, so you can ignore it. >>>>> >>>>>> Later this weekend, >>>>> I will attempt to use CVSup. >>>>> First, >>>>>> I will have to find >>>>> usable documentation, since I >>>>> have >>>>>> never used CVSup >>>>> before. >>>>>> >>>>>> Do you have a >>>>> script to use with CVSup to access the >>>>>> CM3 CVS repo? >>>>> I am lasy. >>>>>> >>>>>> I use 'git' >>>>> for all my current projects. I used >>>>> to use >>>>>> CVS, and had >>>>> started looking into using subversion >>>>> (SVN), >>>>>> I even purchased a >>>>> couple books on SVN. Then >>>>> 'git' burst >>>>>> upon the Linux >>>>> world, and is gaining converts all over >>>>> the >>>>>> place. >>>>>> >>>>>> It really does >>>>> provide a better work-flow. The >>>>> easy >>>>>> creation of a >>>>> branch is a given, it is git's ability >>>>>> to do easy merges, >>>>> which is gaining all the good >>>>> reputation. >>>>>> >>>>>> Rather than get all >>>>> evangelistic on you, as I am sure >>>>> you >>>>>> have already heard >>>>> it many times already. >>>>>> >>>>>> Many businesses are >>>>> moving to git. The only >>>>> problem some >>>>>> enterprise >>>>> companies are having is the ability to >>>>> restrict >>>>>> access of >>>>> authorized users to only portions of the >>>>> repository. >>>>>> These types of >>>>> problems don't effect open source >>>>> software >>>>>> development. >>>>>> >>>>>> Once I have a >>>>> working 'git' repository for cm3, I will >>>>> share >>>>>> the technique, and >>>>> maybe, start the foundations for a >>>>>> transition from >>>>> CVS, towards 'git'. But I >>>>> suggest a slow >>>>>> process, with >>>>> distinct stages. At any >>>>> stage we could stop, >>>>>> or even revert. >>>>>> >>>>>> The problem is that >>>>> once people start using git, they >>>>> don''t >>>>>> want to go back to >>>>> using CVS, or any of the older >>>>> methods. >>>>>> Maybe that >>>>> isn't so much of a problem after all. >>>>>> >>>>>> STAGE-1: Simple >>>>> mirror of the CVS archive, >>>>> periodically >>>>>> >>>>> updated (say once >>>>> every 6 hours). >>>>> Document on >>>>>> >>>>> web site, as to how >>>>> to clone, and update a >>>>> git >>>>>> >>>>> repository. No >>>>> uploads to git. >>>>>> STAGE-2: Convert >>>>> web page scripts to use git. >>>>>> STAGE-3: Convert >>>>> tinderbox. >>>>>> STAGE-4: Uploads to >>>>> git. Install gitosis or >>>>> similar server >>>>>> >>>>> for git uploads. >>>>> Document the upload >>>>> process on web >>>>>> >>>>> pages. >>>>>> STAGE-5: CVS >>>>> mirrors the git repo. Uploads to >>>>> git only. >>>>>> STAGE-6: Move last >>>>> of the CVS people, over to git. >>>>>> STAGE-7: Remove >>>>> CVS. (optional) >>>>> >>>>> Let's see how far >>>>> you get. Converting all the >>>>> infrastructure (scripts >>>>> and documentation) may >>>>> be much more work than you imagine. >>>>> And one >>>>> we propose a special >>>>> tool (be it git or svn or mercurial) >>>>> there will >>>>> start discussions on >>>>> what is best and what we should do >>>>> :-/ >>>>> >>>>> So offering an optional >>>>> alternative access may be a good >>>>> plan. >>>>> The majority of users >>>>> should agree that they want the >>>>> change though. >>>>> And we need to consider >>>>> use of GUIs and Windows users, >>>>> too. >>>>> >>>>> Olaf >>>>> --Olaf Wagner -- elego >>>>> Software Solutions GmbH >>>>> >>>>> >>>>> Gustav-Meyer-Allee 25 / >>>>> Geb?ude 12, 13355 >>>>> Berlin, Germany >>>>> phone: +49 30 23 45 86 >>>>> 96 mobile: +49 177 2345 >>>>> 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com >>>>> | >>>>> Gesch?ftsf?hrer: Olaf >>>>> Wagner | Sitz: Berlin >>>>> Handelregister: >>>>> Amtsgericht Charlottenburg HRB 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> >>>>> >>> Gustav-Meyer-Allee >>>>> 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 >>> 2345 869 >>>>> fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com >>>>> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB >>> 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 13 08:55:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Jul 2009 08:55:57 +0200 Subject: [M3devel] Fwd: Problems with the linker Message-ID: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> Something for Jay or Randy again... please help to find the correct linker. Olaf ----- Forwarded message from clever92000 at yahoo.com.br ----- Date: Sun, 12 Jul 2009 18:51:48 -0300 From: Cleverson Reply-To: Cleverson Subject: Problems with the linker To: m3-support at elego.de Hello: In case my following question can better be answered at the m3devel mailing list, please subscribe me. I'd like to learn Modula-3, so I'm trying to set up CM3 on my Windows XP system. I'm not sure about the differences between the "bin" and the "std" cm3 distributions, but from what I could understand, the later contains more pre-compiled DLL libraries, so I decided to go with it. I unpacked the file "cm3-std-NT386-d5.8.1.zip" to the root of my E: partition, then renamed the root cm3's folder to cm3, then set the PATH variable to include E:\cm3\bin. When I try to build a hello test program, I receive an error saying it cannot find the "link" command, then the linking process fails. The installation instructions state that I should have the Windows SDK. If my problem is actually that I'm missing it, can you point me to where I can grabe it please? Anyways, I'd like to know why cm3 doesn't have its own linker, that it needs the Windows SDK linker, unlike other language's compilers such as FreePascal? Many thanks for any help Cleverson ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 13 09:17:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Jul 2009 07:17:56 +0000 Subject: [M3devel] Fwd: Problems with the linker In-Reply-To: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> References: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> Message-ID: Please buy or download one of the many Visual C++ versions, or one of the Windows SDKs that include a linker. Once installed, they should put a link on the start menu that launches a cmd/console/command line with %PATH% set to include link.exe. I'll make this a little easier maybe, but you still need a Microsoft linker. Options include but are not limited to: http://www.microsoft.com/express/vc/ This might nag you to register but I think to just use the command line you don't have to. http://www.microsoft.com/downloads/details.aspx?familyid=E6E1C3DF-A74F-4207-8586-711EBE331CDC (see how it says "including compilers") some of these: http://mssdk.orderport.net/22221848/showall.asp - Jay > Date: Mon, 13 Jul 2009 08:55:57 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Problems with the linker > > Something for Jay or Randy again... please help to find the correct linker. > > Olaf > > ----- Forwarded message from clever92000 at yahoo.com.br ----- > Date: Sun, 12 Jul 2009 18:51:48 -0300 > From: Cleverson > Reply-To: Cleverson > Subject: Problems with the linker > To: m3-support at elego.de > > Hello: > > In case my following question can better be answered at the m3devel > mailing list, please subscribe me. > > I'd like to learn Modula-3, so I'm trying to set up CM3 on my Windows XP > system. I'm not sure about the differences between the "bin" and the > "std" cm3 distributions, but from what I could understand, the later > contains more pre-compiled DLL libraries, so I decided to go with it. > > I unpacked the file "cm3-std-NT386-d5.8.1.zip" to the root of my E: > partition, then renamed the root cm3's folder to cm3, then set the PATH > variable to include E:\cm3\bin. When I try to build a hello test > program, I receive an error saying it cannot find the "link" command, > then the linking process fails. > > The installation instructions state that I should have the Windows SDK. > If my problem is actually that I'm missing it, can you point me to where > I can grabe it please? > > Anyways, I'd like to know why cm3 doesn't have its own linker, that it > needs the Windows SDK linker, unlike other language's compilers such as > FreePascal? > > Many thanks for any help > > Cleverson > > > ----- End forwarded message ----- > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Mon Jul 13 12:24:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 13 Jul 2009 03:24:58 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <274088.73864.qm@web56804.mail.re3.yahoo.com> Hi Tony, You recent commit, sure looks like it did the trick. CVSup has gotten to the point where it used to crash, and much further. Where before it used to take up over 75% of my memory, now it is at 1.6% (yes, less than 2%). It has also been working for over 14 minutes, and still going strong. Before it wouldn't last for more than 3 minutes. Thank you very much. Another regression bites the dust! +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > >>> From: Tony Hosking > >>> Subject: Re: [M3devel] CVSup crashing WAS: Re: > m3gdb and YACC > >>> To: "Peter Eiserloh" > >>> Cc: "Olaf Wagner" , > m3devel at elegosoft.com > >>> Date: Saturday, July 11, 2009, 2:31 PM > >>> Please try my recent commits from > >>> earlier to day. > >>> From jay.krell at cornell.edu Tue Jul 14 02:10:30 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 13 Jul 2009 17:10:30 -0700 Subject: [M3devel] dynamic linking broken In-Reply-To: References: Message-ID: <28CA8259-DA9C-4A4F-AA1B-1F01CFE3DE2B@hotmail.com> It should be ok now though I didn't test the solaris part. Hopefully a better construct soon like 'InstallSymbolicLink' without the limitations of the current functions, to reduce the indirection. - Jay (phone) On Jul 12, 2009, at 7:55 PM, Jay K wrote: > It looks like I might have broken dynamic linking, when I > moved .so/.dylib files only to lib and not in pkg. > > At least on AMD64_DARWIN we get link commands like > > -L /cm3/pkg/m3core -lm3core > > but that directory only has libm3core.a. > > I'll investigate further and fix. > > Two likely fixes: > 1 Change cm3 to point -L always just at /cm3/lib instead of /cm3/pkg. > 2 symlink pkg out to lib > > - Jay > > > > From wagner at elegosoft.com Wed Jul 15 08:31:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 08:31:40 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze Message-ID: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Hi all, I'm currently tagging the source base with release_CM3_5_8_RC2. The reported compiler vesion will be d5.8.2 for this RC. There seems to be a neverending stream of commits, which makes it quite difficult to choose a good time to do this, but I hope that Tinderbox will show no major problems with the tagged sources. I'd like everybody for the next weeks to postpone their functional changes and concentrate on testing and fixing bugs that are found or already known. If anybody knows of any problems with the current tag we can still move it in places _before_ we build any release archives. Tagging the whole repository is a quite costly operation in CVS. To summarize: o refrain from functional changes o report and correct bugs o don't build any distribution archives until we've agreed we've tagged a good source set I'll perform some testing myself and try to prepare a draft for the release notes (a lot of changes occured in the recent years) within the next days. Thanks for your patience and your contribution, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 09:27:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 07:27:44 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: How does one checkout, update or commit to RC2 and beyond RC2? There is still maybe the formsedit crash. I'll verify soon. Ideally we get to a situation in which distributions are built every day and what we ship is merely picked among them. I need to ever get Tinderbox working and under cron or in a loop. I also wonder if we should go back to 5.7.something, since we burned through 5.7 fairly fast. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 08:31:40 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: m3-support at elego.de > Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > There seems to be a neverending stream of commits, which makes > it quite difficult to choose a good time to do this, but I hope > that Tinderbox will show no major problems with the tagged sources. > > I'd like everybody for the next weeks to postpone their functional > changes and concentrate on testing and fixing bugs that are found > or already known. If anybody knows of any problems with the current > tag we can still move it in places _before_ we build any release > archives. Tagging the whole repository is a quite costly operation > in CVS. > > To summarize: > > o refrain from functional changes > o report and correct bugs > o don't build any distribution archives until we've agreed we've > tagged a good source set > > I'll perform some testing myself and try to prepare a draft for the > release notes (a lot of changes occured in the recent years) within the > next days. > > Thanks for your patience and your contribution, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 15 11:33:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 11:33:56 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Quoting Jay K : > How does one checkout, update or commit to RC2 and beyond RC2? No changes here. I'd just like to avoid branching for the release, and concentrate work on it. > There is still maybe the formsedit crash. I'll verify soon. > > Ideally we get to a situation in which distributions are built every > day and what we ship is merely picked among them. I need to ever > get Tinderbox working and under cron or in a loop. > > I also wonder if we should go back to 5.7.something, since we burned > through 5.7 fairly fast. Please, let's just provide one stable official release, and not confuse anybody by using old version numbers. Olaf > ---------------------------------------- >> Date: Wed, 15 Jul 2009 08:31:40 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> CC: m3-support at elego.de >> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> There seems to be a neverending stream of commits, which makes >> it quite difficult to choose a good time to do this, but I hope >> that Tinderbox will show no major problems with the tagged sources. >> >> I'd like everybody for the next weeks to postpone their functional >> changes and concentrate on testing and fixing bugs that are found >> or already known. If anybody knows of any problems with the current >> tag we can still move it in places _before_ we build any release >> archives. Tagging the whole repository is a quite costly operation >> in CVS. >> >> To summarize: >> >> o refrain from functional changes >> o report and correct bugs >> o don't build any distribution archives until we've agreed we've >> tagged a good source set >> >> I'll perform some testing myself and try to prepare a draft for the >> release notes (a lot of changes occured in the recent years) within the >> next days. >> >> Thanks for your patience and your contribution, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 13:41:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 11:41:38 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715113356.30raw28b74og08kk@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: I'd still like to: reduce the indirection in the recently introduced symlinks..it is a small change (that's what I always say!) (though the movement from pkg to lib I wouldn't call small) improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others These might be be mostly just: - updating RTSignalC.c - updating the GNU configuration name for AMD64_SOLARIS in m3cc/src/m3makefile - fix my Python scripts to consume the master package list, build m3gdb, build cm3ide, build in dependency order (huh, I thought they always did, now not sure), add your feature of passing on extra parameteres to cm3 - maybe change the *.sh files to accept parameters in any order like the *.py - maybe whittle away more on m3core/src/unix Also some minor features I'll propose shortly. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 11:33:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > Quoting Jay K : > >> How does one checkout, update or commit to RC2 and beyond RC2? > > No changes here. I'd just like to avoid branching for the release, > and concentrate work on it. > >> There is still maybe the formsedit crash. I'll verify soon. >> >> Ideally we get to a situation in which distributions are built every >> day and what we ship is merely picked among them. I need to ever >> get Tinderbox working and under cron or in a loop. >> >> I also wonder if we should go back to 5.7.something, since we burned >> through 5.7 fairly fast. > > Please, let's just provide one stable official release, and not confuse > anybody by using old version numbers. > > Olaf > >> ---------------------------------------- >>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> CC: m3-support at elego.de >>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>> >>> Hi all, >>> >>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>> The reported compiler vesion will be d5.8.2 for this RC. >>> There seems to be a neverending stream of commits, which makes >>> it quite difficult to choose a good time to do this, but I hope >>> that Tinderbox will show no major problems with the tagged sources. >>> >>> I'd like everybody for the next weeks to postpone their functional >>> changes and concentrate on testing and fixing bugs that are found >>> or already known. If anybody knows of any problems with the current >>> tag we can still move it in places _before_ we build any release >>> archives. Tagging the whole repository is a quite costly operation >>> in CVS. >>> >>> To summarize: >>> >>> o refrain from functional changes >>> o report and correct bugs >>> o don't build any distribution archives until we've agreed we've >>> tagged a good source set >>> >>> I'll perform some testing myself and try to prepare a draft for the >>> release notes (a lot of changes occured in the recent years) within the >>> next days. >>> >>> Thanks for your patience and your contribution, >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 15 14:01:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 12:01:43 +0000 Subject: [M3devel] TARGET_OS, TARGET_PROCESSOR, TARGET_ENDIAN? Message-ID: I propose there be quake variables, set by by cm3 in Target.m3 with the possible names/values: TARGET_OS: ?TARGET_KERNEL, ?TARGET_LIBC (which /sort of/ makes sense but surely wouldn't be the conclusion) FREEBSD, NETBSD, OPENBSD, DARWIN, LINUX, SOLARIS, NT, CYGWIN, INETRIX, TRU64 (OSF1?), VMS, HPUX, IRIX, AIX, HERD?, GNUHERD?, GNU??, PLAN9?, MACOS?, DJGPP?, MSDOS? TARGET_PROCESSOR: ?TARGET_CPU, ?TARGET_ARCHITECTURE, ?TARGET_PROCESSOR_ARCHITECTURE I386, AMD64, SPARC, SPARC64, PPC, PPC64, ARM, MIPS, MIPS64, ALPHA, IA64, M68K?, SH3?, SH4? (I doubt these last three will ever be supported.) I grant that this is somewhat redundant with WORD_SIZE. You could just have X86, SPARC, PPC, MIPS, and dispense with AMD64, SPARC64, PPC64, MIPS64. TARGET_ENDIAN: BIG, LITTLE This would allow for much smoother maintenance of a few m3makefiles, since a lot of stuff keyed by TARGET need only be keyed by one of these factors. I also propose, maybe, there be similar HOST_ variables where above I have TARGET_. Though these have far less utility. If I didn't already introduce it, HOST_OSTYPE is about the right thing here -- POSIX or WIN32. I also put in HOST which draws from the same values as TARGET, really just as a default for TARGET when probing for config files. I also grant that I'm ignoring some harder to pin down problems such as "TARGET_ABI" -- 32bit MIPS has two, and IA64 has a surprising number -- there are actually 32bit ABIs on IA64_HPUX, we'd probably never support them. Ideally but not always, TARGET = TARGET_PROCESSOR + TARGET_OS? - Jay From wagner at elegosoft.com Wed Jul 15 16:01:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 16:01:23 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: <20090715160123.zrxx74tg2ssoc8cg@mail.elegosoft.com> Quoting Jay K : > I'd still like to: > > reduce the indirection in the recently introduced symlinks..it is > a small change (that's what I always say!) (though the movement from > pkg to lib I wouldn't call small) > > improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, > AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, > AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others > > These might be be mostly just: > - updating RTSignalC.c Minor corrections and improvements can still be made for the next release candidate (RC3), or release (if we agree that RC2 is OK ;-) > - updating the GNU configuration name for AMD64_SOLARIS in > m3cc/src/m3makefile > - fix my Python scripts to consume the master package list, > build m3gdb, build cm3ide, build in dependency order (huh, I thought > they always did, now not sure), add your feature of passing on > extra parameteres to cm3 > - maybe change the *.sh files to accept parameters in any order > like the *.py > - maybe whittle away more on m3core/src/unix > > Also some minor features I'll propose shortly. Well, we originally wanted to deliver a release (which has been overdue for many years) in May; now it's mid of July. There's always lots of stuff we can improve, but why not do it in the next release? We'll never get anything released if we continue adding new things... Olaf > ---------------------------------------- >> Date: Wed, 15 Jul 2009 11:33:56 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Quoting Jay K : >> >>> How does one checkout, update or commit to RC2 and beyond RC2? >> >> No changes here. I'd just like to avoid branching for the release, >> and concentrate work on it. >> >>> There is still maybe the formsedit crash. I'll verify soon. >>> >>> Ideally we get to a situation in which distributions are built every >>> day and what we ship is merely picked among them. I need to ever >>> get Tinderbox working and under cron or in a loop. >>> >>> I also wonder if we should go back to 5.7.something, since we burned >>> through 5.7 fairly fast. >> >> Please, let's just provide one stable official release, and not confuse >> anybody by using old version numbers. >> >> Olaf >> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: m3-support at elego.de >>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Hi all, >>>> >>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>> The reported compiler vesion will be d5.8.2 for this RC. >>>> There seems to be a neverending stream of commits, which makes >>>> it quite difficult to choose a good time to do this, but I hope >>>> that Tinderbox will show no major problems with the tagged sources. >>>> >>>> I'd like everybody for the next weeks to postpone their functional >>>> changes and concentrate on testing and fixing bugs that are found >>>> or already known. If anybody knows of any problems with the current >>>> tag we can still move it in places _before_ we build any release >>>> archives. Tagging the whole repository is a quite costly operation >>>> in CVS. >>>> >>>> To summarize: >>>> >>>> o refrain from functional changes >>>> o report and correct bugs >>>> o don't build any distribution archives until we've agreed we've >>>> tagged a good source set >>>> >>>> I'll perform some testing myself and try to prepare a draft for the >>>> release notes (a lot of changes occured in the recent years) within the >>>> next days. >>>> >>>> Thanks for your patience and your contribution, >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Wed Jul 15 18:14:45 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Wed, 15 Jul 2009 12:14:45 -0400 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: <4A5DC833.1E75.00D7.1@scires.com> Olaf: Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. I'll try to work on this tonight. Thanks for getting us to this stage in the process! Regards, Randy Coleburn >>> Olaf Wagner 7/15/2009 2:31 AM >>> Hi all, I'm currently tagging the source base with release_CM3_5_8_RC2. The reported compiler vesion will be d5.8.2 for this RC. .. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Wed Jul 15 18:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 16:24:49 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <4A5DC833.1E75.00D7.1@scires.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: I think from Olaf's response to my question, you just do a regular "update" with no special parameters. Can some/all of your applications be in the cm3 repository? - Jay ________________________________ > Date: Wed, 15 Jul 2009 12:14:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Olaf: > > > > Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. > > > > I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. > > > > I'll try to work on this tonight. > > > > Thanks for getting us to this stage in the process! > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/15/2009 2:31 AM>>> > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > ... From wagner at elegosoft.com Wed Jul 15 19:12:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 19:12:41 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: <20090715191241.ykphdt1we68ooccs@mail.elegosoft.com> Quoting Jay K : > > I think from Olaf's response to my question, you just do a regular > "update" with no special parameters. I just checked: there have been no commits since I laid the tag this morning, so the current head is still equal to release_CM3_5_8_RC2. Randy, I haven't got TurtoiseCVS here, but I'd guess you can specify the tag in the checkout of update dialogue. If you check out release_CM3_5_8_RC2, CVS will just make that tag `sticky' (remember it in your workspace) and not let you do any updates (since it is no branch). Jay, I really don't want to repress all your activities, I'd just like you to consider if they are really necessary for this release (candidate) or if they can wait some more days. As I said, we can still incorporate minor improvements by moving the tag, but once we build packages, we should not touch it any more. Everything else can of course go into RC3 as long as it does not challenge the stability. Does that sound OK? Olaf > Can some/all of your applications be in the cm3 repository? > > - Jay > > > ________________________________ >> Date: Wed, 15 Jul 2009 12:14:45 -0400 >> From: rcolebur at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> >> >> >> >> >> >> Olaf: >> >> >> >> Ok, so now that you have RC2, I suppose I need to update my local >> copy of the repository to match RC2, rebuild everything, and test >> my applications to see how it fares. >> >> >> >> I'm using TortoiseCVS. If I just do a CVS update, I get everything >> that has changed in the repository, so I need to do some >> investigating to see how to get just the RC2 stuff. >> >> >> >> I'll try to work on this tonight. >> >> >> >> Thanks for getting us to this stage in the process! >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Olaf Wagner 7/15/2009 2:31 AM>>> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> ... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Wed Jul 15 19:33:36 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Wed, 15 Jul 2009 13:33:36 -0400 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: <4A5DDAB0.1E75.00D7.1@scires.com> Jay, No, I can't put all of my applications into the repository because many of them are "works for hire" and the source code cannot be released to the public domain. Regards, Randy >>> Jay K 7/15/2009 12:24 PM >>> I think from Olaf's response to my question, you just do a regular "update" with no special parameters. Can some/all of your applications be in the cm3 repository? - Jay ________________________________ > Date: Wed, 15 Jul 2009 12:14:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Olaf: > > > > Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. > > > > I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. > > > > I'll try to work on this tonight. > > > > Thanks for getting us to this stage in the process! > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/15/2009 2:31 AM>>> > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Wed Jul 15 19:35:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 19:35:01 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> OK< I've done the first changes to RC2 myself now:-/ cvs commit -m 'consistently rename programs lex, yacc, tok, ext to klex, kyacc, ktok, kext' caltech-parser The following files have been changed: T caltech-parser/parserlib/kext/src/m3makefile T caltech-parser/parserlib/klex/src/m3makefile T caltech-parser/parserlib/ktok/src/m3makefile T caltech-parser/parserlib/kyacc/src/m3makefile T caltech-parser/parserlib/parserlib/src/parser.tmpl I think that change is justified as we do not want to ship competing yaccs and lexs again, that's rather surprising (not to say annoying). I'd suggest we'll wait another day for late fixes and then build the RC2 packages. Any comments/suggestions so far? Olaf Quoting Jay K : > I'd still like to: > > reduce the indirection in the recently introduced symlinks..it is > a small change (that's what I always say!) (though the movement from > pkg to lib I wouldn't call small) > > > improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, > AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, > AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others > > These might be be mostly just: > - updating RTSignalC.c > - updating the GNU configuration name for AMD64_SOLARIS in > m3cc/src/m3makefile > - fix my Python scripts to consume the master package list, > build m3gdb, build cm3ide, build in dependency order (huh, I thought > they always did, now not sure), add your feature of passing on > extra parameteres to cm3 > - maybe change the *.sh files to accept parameters in any order > like the *.py > - maybe whittle away more on m3core/src/unix > > Also some minor features I'll propose shortly. > > - Jay > > > > > > > > ---------------------------------------- >> Date: Wed, 15 Jul 2009 11:33:56 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Quoting Jay K : >> >>> How does one checkout, update or commit to RC2 and beyond RC2? >> >> No changes here. I'd just like to avoid branching for the release, >> and concentrate work on it. >> >>> There is still maybe the formsedit crash. I'll verify soon. >>> >>> Ideally we get to a situation in which distributions are built every >>> day and what we ship is merely picked among them. I need to ever >>> get Tinderbox working and under cron or in a loop. >>> >>> I also wonder if we should go back to 5.7.something, since we burned >>> through 5.7 fairly fast. >> >> Please, let's just provide one stable official release, and not confuse >> anybody by using old version numbers. >> >> Olaf >> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: m3-support at elego.de >>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Hi all, >>>> >>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>> The reported compiler vesion will be d5.8.2 for this RC. >>>> There seems to be a neverending stream of commits, which makes >>>> it quite difficult to choose a good time to do this, but I hope >>>> that Tinderbox will show no major problems with the tagged sources. >>>> >>>> I'd like everybody for the next weeks to postpone their functional >>>> changes and concentrate on testing and fixing bugs that are found >>>> or already known. If anybody knows of any problems with the current >>>> tag we can still move it in places _before_ we build any release >>>> archives. Tagging the whole repository is a quite costly operation >>>> in CVS. >>>> >>>> To summarize: >>>> >>>> o refrain from functional changes >>>> o report and correct bugs >>>> o don't build any distribution archives until we've agreed we've >>>> tagged a good source set >>>> >>>> I'll perform some testing myself and try to prepare a draft for the >>>> release notes (a lot of changes occured in the recent years) within the >>>> next days. >>>> >>>> Thanks for your patience and your contribution, >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 20:35:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 18:35:30 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <4A5DDAB0.1E75.00D7.1@scires.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> <4A5DDAB0.1E75.00D7.1@scires.com> Message-ID: Understood, I had to ask just in case. (I was going to explain the various licenses but...) - Jay ________________________________ > Date: Wed, 15 Jul 2009 13:33:36 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Jay, > > > > No, I can't put all of my applications into the repository because many of them are "works for hire" and the source code cannot be released to the public domain. > > > > Regards, > > Randy > >>>> Jay K 7/15/2009 12:24 PM>>> > > I think from Olaf's response to my question, you just do a regular "update" with no special parameters. > > Can some/all of your applications be in the cm3 repository? > > - Jay > > > ________________________________ >> Date: Wed, 15 Jul 2009 12:14:45 -0400 >> From: rcolebur at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> >> >> >> >> >> >> Olaf: >> >> >> >> Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. >> >> >> >> I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. >> >> >> >> I'll try to work on this tonight. >> >> >> >> Thanks for getting us to this stage in the process! >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Olaf Wagner 7/15/2009 2:31 AM>>> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> .. From jay.krell at cornell.edu Wed Jul 15 20:37:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 18:37:10 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: Definitely these should be renamed from what they are. Does "kext" bother anyone else, enough to come up with another name? kext is the extension for "kernel extensions" on Darwin -- drivers. Maybe I can get one more change in in the day window. :) Or it can be in after the RC, ok. It's a very compatible and fairly desirable change, to shorten the symlink chain lengths. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 19:35:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > OK< I've done the first changes to RC2 myself now:-/ > > cvs commit -m 'consistently rename programs lex, yacc, tok, ext to > klex, kyacc, ktok, kext' caltech-parser > > The following files have been changed: > T caltech-parser/parserlib/kext/src/m3makefile > T caltech-parser/parserlib/klex/src/m3makefile > T caltech-parser/parserlib/ktok/src/m3makefile > T caltech-parser/parserlib/kyacc/src/m3makefile > T caltech-parser/parserlib/parserlib/src/parser.tmpl > > I think that change is justified as we do not want to ship competing > yaccs and lexs again, that's rather surprising (not to say annoying). > > I'd suggest we'll wait another day for late fixes and then build > the RC2 packages. > Any comments/suggestions so far? > > Olaf > > Quoting Jay K : > >> I'd still like to: >> >> reduce the indirection in the recently introduced symlinks..it is >> a small change (that's what I always say!) (though the movement from >> pkg to lib I wouldn't call small) >> >> >> improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, >> AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, >> AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others >> >> These might be be mostly just: >> - updating RTSignalC.c >> - updating the GNU configuration name for AMD64_SOLARIS in >> m3cc/src/m3makefile >> - fix my Python scripts to consume the master package list, >> build m3gdb, build cm3ide, build in dependency order (huh, I thought >> they always did, now not sure), add your feature of passing on >> extra parameteres to cm3 >> - maybe change the *.sh files to accept parameters in any order >> like the *.py >> - maybe whittle away more on m3core/src/unix >> >> Also some minor features I'll propose shortly. >> >> - Jay >> >> >> >> >> >> >> >> ---------------------------------------- >>> Date: Wed, 15 Jul 2009 11:33:56 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; m3-support at elego.de >>> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>> >>> Quoting Jay K : >>> >>>> How does one checkout, update or commit to RC2 and beyond RC2? >>> >>> No changes here. I'd just like to avoid branching for the release, >>> and concentrate work on it. >>> >>>> There is still maybe the formsedit crash. I'll verify soon. >>>> >>>> Ideally we get to a situation in which distributions are built every >>>> day and what we ship is merely picked among them. I need to ever >>>> get Tinderbox working and under cron or in a loop. >>>> >>>> I also wonder if we should go back to 5.7.something, since we burned >>>> through 5.7 fairly fast. >>> >>> Please, let's just provide one stable official release, and not confuse >>> anybody by using old version numbers. >>> >>> Olaf >>> >>>> ---------------------------------------- >>>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> CC: m3-support at elego.de >>>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>>> >>>>> Hi all, >>>>> >>>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>>> The reported compiler vesion will be d5.8.2 for this RC. >>>>> There seems to be a neverending stream of commits, which makes >>>>> it quite difficult to choose a good time to do this, but I hope >>>>> that Tinderbox will show no major problems with the tagged sources. >>>>> >>>>> I'd like everybody for the next weeks to postpone their functional >>>>> changes and concentrate on testing and fixing bugs that are found >>>>> or already known. If anybody knows of any problems with the current >>>>> tag we can still move it in places _before_ we build any release >>>>> archives. Tagging the whole repository is a quite costly operation >>>>> in CVS. >>>>> >>>>> To summarize: >>>>> >>>>> o refrain from functional changes >>>>> o report and correct bugs >>>>> o don't build any distribution archives until we've agreed we've >>>>> tagged a good source set >>>>> >>>>> I'll perform some testing myself and try to prepare a draft for the >>>>> release notes (a lot of changes occured in the recent years) within the >>>>> next days. >>>>> >>>>> Thanks for your patience and your contribution, >>>>> >>>>> Olaf >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 15 21:08:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 15 Jul 2009 12:08:28 -0700 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: I meant to say from what they *were*. I only have to whine non zero about 'kext' I don't insist or such. What they *are* is fine. I was agreeing but accidentally disagreed. - oops (phone) On Jul 15, 2009, at 11:37 AM, Jay K wrote: > > Definitely these should be renamed from what they are. > Does "kext" bother anyone else, enough to come up with another name? > kext is the extension for "kernel extensions" on Darwin -- drivers. > > Maybe I can get one more change in in the day window. :) Or it can > be in after the RC, ok. It's a very compatible and fairly desirable > change, to shorten the symlink chain lengths. > > - Jay > > > ---------------------------------------- >> Date: Wed, 15 Jul 2009 19:35:01 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> OK< I've done the first changes to RC2 myself now:-/ >> >> cvs commit -m 'consistently rename programs lex, yacc, tok, ext to >> klex, kyacc, ktok, kext' caltech-parser >> >> The following files have been changed: >> T caltech-parser/parserlib/kext/src/m3makefile >> T caltech-parser/parserlib/klex/src/m3makefile >> T caltech-parser/parserlib/ktok/src/m3makefile >> T caltech-parser/parserlib/kyacc/src/m3makefile >> T caltech-parser/parserlib/parserlib/src/parser.tmpl >> >> I think that change is justified as we do not want to ship competing >> yaccs and lexs again, that's rather surprising (not to say annoying). >> >> I'd suggest we'll wait another day for late fixes and then build >> the RC2 packages. >> Any comments/suggestions so far? >> >> Olaf >> >> Quoting Jay K : >> >>> I'd still like to: >>> >>> reduce the indirection in the recently introduced symlinks..it is >>> a small change (that's what I always say!) (though the movement from >>> pkg to lib I wouldn't call small) >>> >>> >>> improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, >>> AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, >>> AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others >>> >>> These might be be mostly just: >>> - updating RTSignalC.c >>> - updating the GNU configuration name for AMD64_SOLARIS in >>> m3cc/src/m3makefile >>> - fix my Python scripts to consume the master package list, >>> build m3gdb, build cm3ide, build in dependency order (huh, I thought >>> they always did, now not sure), add your feature of passing on >>> extra parameteres to cm3 >>> - maybe change the *.sh files to accept parameters in any order >>> like the *.py >>> - maybe whittle away more on m3core/src/unix >>> >>> Also some minor features I'll propose shortly. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 11:33:56 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com; m3-support at elego.de >>>> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Quoting Jay K : >>>> >>>>> How does one checkout, update or commit to RC2 and beyond RC2? >>>> >>>> No changes here. I'd just like to avoid branching for the release, >>>> and concentrate work on it. >>>> >>>>> There is still maybe the formsedit crash. I'll verify soon. >>>>> >>>>> Ideally we get to a situation in which distributions are built >>>>> every >>>>> day and what we ship is merely picked among them. I need to ever >>>>> get Tinderbox working and under cron or in a loop. >>>>> >>>>> I also wonder if we should go back to 5.7.something, since we >>>>> burned >>>>> through 5.7 fairly fast. >>>> >>>> Please, let's just provide one stable official release, and not >>>> confuse >>>> anybody by using old version numbers. >>>> >>>> Olaf >>>> >>>>> ---------------------------------------- >>>>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: m3devel at elegosoft.com >>>>>> CC: m3-support at elego.de >>>>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>>>> The reported compiler vesion will be d5.8.2 for this RC. >>>>>> There seems to be a neverending stream of commits, which makes >>>>>> it quite difficult to choose a good time to do this, but I hope >>>>>> that Tinderbox will show no major problems with the tagged >>>>>> sources. >>>>>> >>>>>> I'd like everybody for the next weeks to postpone their >>>>>> functional >>>>>> changes and concentrate on testing and fixing bugs that are found >>>>>> or already known. If anybody knows of any problems with the >>>>>> current >>>>>> tag we can still move it in places _before_ we build any release >>>>>> archives. Tagging the whole repository is a quite costly >>>>>> operation >>>>>> in CVS. >>>>>> >>>>>> To summarize: >>>>>> >>>>>> o refrain from functional changes >>>>>> o report and correct bugs >>>>>> o don't build any distribution archives until we've agreed we've >>>>>> tagged a good source set >>>>>> >>>>>> I'll perform some testing myself and try to prepare a draft for >>>>>> the >>>>>> release notes (a lot of changes occured in the recent years) >>>>>> within the >>>>>> next days. >>>>>> >>>>>> Thanks for your patience and your contribution, >>>>>> >>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>> Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz >>>> : Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be >> rlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> From eiserlohpp at yahoo.com Thu Jul 16 03:19:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 15 Jul 2009 18:19:49 -0700 (PDT) Subject: [M3devel] M3Config contains paths to installation directory. Message-ID: <645960.77867.qm@web56801.mail.re3.yahoo.com> Hi Jay, Do you know of any way to tell the build system that the final installation directory is located in one place, but that the software is to actually be shipped (temporarily) to a staging directory. Specifically, libm3/src/config contains a m3makefile that derives the M3Config interface, containing a number of paths to the installation root directory. This is the normal situation for most people, but I am installing to a temporary directory, for packaging purposes. The packaging software later installs the package into the correct location. Whenever I build the system, M3Config always contains the paths to my staging area. I would like some way of specifying to the build system that the final (or real) installation root is one thing, but "ship" would actually install into a different one. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Thu Jul 16 04:46:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 02:46:35 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: 1) I do wonder if this is what PKG_USE vs. PKG_INSTALL is but not sure. 2) You can achieve your goal easily anyway? Like, stick -R/usr/local/lib in the right place? Appropriately generalized? That is -- introduce another variable, DESTDIR? I content that we have significant/complete control of all the config files, so you can feel able to go into m3-sys/cminstall/src/config-no-install and sprinkle like DESTDIR="/usr/local/cm3" into all the files, or just into cm3cfg.common. 3) Can you just avoid knowing it? > libm3/src/config Hm. Maybe we examine it, deem it "problematic", and reduce or remove its functionality, such as to eliminate your problem? Assume there aren't many users and watch for the fallout? Or maybe, and again, I have to look at it, but maybe whatever data is exposed here can be computed at runtime instead of build-time, assuming dynamic linking to libm3core.so? In Windows it is easy enough for some code at runtime to gets the path to the file (.exe, .dll) it is in. Other systems? So I think, using that, this interface can generate the data at runtime instead of build-time. Which may or maybe be what you want -- the "official " or "default" install location, or the actual "current" location? - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 18:19:49 -0700 > From: eiserlohpp at yahoo.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] M3Config contains paths to installation directory. > > > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Thu Jul 16 05:25:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 03:25:48 +0000 Subject: [M3devel] how to port to new target Message-ID: "how to port" I know there is a web already but maybe it needs updating. (Maybe not, basically just one item stricken/reduced). Based on the AMD64_NETBSD/OPENBSD work (ChangeLog entry), and /assuming/ gcc has already been ported, here is a/the specific current list of files that need visiting for porting: add a file to m3-sys/cminstall/src/config-no-install m3-sys/m3middle/src/Target.m3 m3-sys/m3middle/src/Target.i3 (trivial, just add to the list) m3-libs/m3core/src/runtime/common/Compiler.tmpl (trivial) add m3-libs/m3core/src/C/TARGET/Csetjmp.i3 (redundant with Target.m3) add m3-libs/m3core/src/C/TARGET/m3makefile (trivial, always the same) all these trivial: m3-libs/m3core/src/thread.quake m3-libs/libm3/src/os/POSIX/m3makefile m3-libs/libm3/src/random/m3makefile m3-libs/m3core/src/C/Common/m3makefile m3-libs/m3core/src/Csupport/m3makefile m3-libs/m3core/src/float/m3makefile m3-libs/m3core/src/runtime/m3makefile m3-libs/m3core/src/runtime/POSIX/m3makefile m3-libs/m3core/src/runtime/common/m3makefile m3-libs/m3core/src/time/POSIX/m3makefile m3-libs/m3core/src/unix/Common/m3makefile plus off the top of my head: scripts/sysinfo.sh -- platform detection using uname etc. scripts/python/pylib.py -- platform detection and possible changes to "boot" (redundant with config file sorry) m3-sys/m3cc/src/m3makefile -- at least add the TARGET => GNU_PLATFORM mapping for building a cross compiler; sometimes more is needed m3-sys/m3gdb/src/m3makefile -- ditto m3-libs/m3core/src/runtime/POSIX/RTSignalC.c for adding a new processor for Solaris or NetBSD, maybe already portable, but otherwise this file is highly target specific, though you can also just fallback and return 0. I'd rather not put in the fallback, lest porters don't get a "reminder". They can always make it so upon being reminded. (The reminder comes unfortunately late -- when native building the boot archive on the target platform.) plus some possible revisitation of: m3-libs/m3core/src/unix/Common but often just works. Adding a new processor for Darwin is a little different than other platforms. Threading is a little different, in a good way and you might to use Apple's fork of gcc (see m3cc/m3makefile, look for ARM_DARWIN). In future maybe things go a little different, like if there are more builtin backends or stack walkers. (Though I'm hoping for a fairly portable stack walker using libgcc/libunwind.) It should be possible to significantly reduce this if you are only adding another processor for an existing OS, or just another OS for existing processor. A lot of the checks only depend on endian or OS. Granted it is not a long list asis. If there is non-Posix non-NT platform, more work. - Jay From rodney.m.bates at cox.net Thu Jul 16 02:30:14 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 15 Jul 2009 19:30:14 -0500 Subject: [M3devel] Release notes comments Message-ID: <4A5E7496.7020308@cox.net> A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. From wagner at elegosoft.com Thu Jul 16 08:24:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 08:24:22 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <4A5E7496.7020308@cox.net> References: <4A5E7496.7020308@cox.net> Message-ID: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Quoting "Rodney M. Bates" : > A couple of comments on the release notes for 5.8.2:
  • System > pthread threading is now the default on all > platforms. The original (fast) M3 user level thread code is > still there and can be used if necessary (on most platforms). On > many systems, this allows M3 applications to scale over all > available hardware processors.
  • > > This sounds like it is the original user level threads that allow > scaling over multiple processors, which I believe is backwards. I > suggest swapping the second and third sentences be for clarity. >
  • New data type LONGINT (64 bit integer) on all target > platforms except Windows (still in the queue).
  • > > As I understand it, LONGINT is in Windows too, it just isn't 64 > bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 16 08:44:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 08:44:14 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> Please remind me again what exactly depends on this interface and why we do it that way. In cm3 I find quake variables like these (* Default to a native build, so the config file can say less. *) Quake.Define(mach, "TARGET", M3Config.TARGET); Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); Quake.Define(mach, "BACKEND_MODE", Version.BackendMode); Quake.Define(mach, "C_COMPILER", Version.CCompiler); Quake.Define(mach, "LINKER", Version.Linker); Quake.Define(mach, "THREAD_LIBRARY", Version.ThreadLibrary); Quake.Define(mach, "WINDOW_LIBRARY", Version.WindowLibrary); Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); (* Even if the config file overrides the defaults, such as to do a cross build, the host characteristics are still available. *) Quake.Define(mach, "HOST", M3Config.TARGET); Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); but no installation paths. Most code uses MxConfig AS M3Config. I see it's used in m3browser as package_root deault, but that can surely be fixed and it can also be specified on the command line. Same in m3tohtml. So why is it needed? One obvious way to overcome Peter's problem would of course be to pass a parameter block to quake when building ("m3config-overrides"?). Better perhaps to get rid of these paths. Olaf Quoting Peter Eiserloh : > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 16 09:43:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 07:43:22 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> Message-ID: I'm pretty confident we can fix this fairly soon. Many M3Config users can/should be replaced with MxConfig. MxConfig can be augmented with "static" things like OS_TYPE, PATH_SEP. Capturing stuff like PKG_USE at compile time is quite bogus, except as part of some sort of "cm3 -v" like how gcc reports its configure command line. But that wouldn't be in a public interface. Can anyone confirm the theory I just invented as to the history here? M3Config existed. M3Config was recognized as broken. MxConfig introduced as a replacement for M3Config. This "AS" construct I see used rarely, makes me thing something a little unusual afoot here, and "getting something very wrong the first time" seems to be unusual in M3. :) Doing the same grep that Olaf did... C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(177): CopyTextArray(self.options.addSearchDir,M3Config.PKG_USE & broken C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(178): M3Config.PATH_SEP & "sgml" & M3Config.PATH_SEP & "src" & C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(179): M3Config.PATH_SEP & "dtd"); ok, augment MxConfig with this data C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(57): env := NewEnv("target", NewText(M3Config.TARGET), env); C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(58): env := NewEnv("osType", NewText(M3Config.OS_TYPE), env); C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(59): env := NewEnv("pathSep", NewText(M3Config.PATH_SEP), env); ditto C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, "TARGET", M3Config.TARGET); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, "HOST", M3Config.TARGET); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); I put all these in and they are all ok, but also ditto. (The idea being we end up with only MxConfig and no M3Config.) C:\dev2\cm3.2\m3-sys\cm3ide\src\misc\Default.m3(35): build_dir := M3Config.Get ("BUILD_DIR"); C:\dev2\cm3.2\m3-sys\cm3ide\src\misc\Default.m3(36): system_root := M3Config.Get ("PKG_USE"); (* note: system_root is the public package root *) These are all really MxConfig, everything in this file, ok. C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(22): SLASH = M3Config.PATH_SEP; ok C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(31): package_root := M3Config.PKG_USE; broken C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(37): derived_dirs := IntList.List1 (ID.Add (M3Config.BUILD_DIR)); slightly broken C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(137): pkgRoot := M3Config.PKG_USE; broken C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(243): proj_pkg := pkgRoot & M3Config.PATH_SEP & pkg; ok C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(281): IF Text.GetChar (filename, i) # Text.GetChar (M3Config.BUILD_DIR, i) THEN slightly broken, BUILD_DIR is not necessarily TARGET, though if/when we provide CM3_OUTPUT_ROOT, BUILD_DIR can go away, or just be really synonymous with TARGET. C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(287): IF Text.GetChar (filename, i) = Text.GetChar (M3Config.PATH_SEP, 0) THEN ok C:\dev2\cm3.2\m3-tools\m3tohtml\src\Msg.m3(38): IF Text.Equal(M3Config.OS_TYPE, "WIN32") THEN ok, but there is a better way, something like Wr.EOL or OSConfig.LineSep, which are completely redundant, and Wr.EOL ideally would be a constant. later.. - Jay > Date: Thu, 16 Jul 2009 08:44:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > Please remind me again what exactly depends on this interface > and why we do it that way. > > In cm3 I find quake variables like these > > (* Default to a native build, so the config file can say less. *) > > Quake.Define(mach, "TARGET", M3Config.TARGET); > Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); > Quake.Define(mach, "BACKEND_MODE", Version.BackendMode); > Quake.Define(mach, "C_COMPILER", Version.CCompiler); > Quake.Define(mach, "LINKER", Version.Linker); > Quake.Define(mach, "THREAD_LIBRARY", Version.ThreadLibrary); > Quake.Define(mach, "WINDOW_LIBRARY", Version.WindowLibrary); > Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); > > (* Even if the config file overrides the defaults, such as to do > a cross build, the host characteristics are still available. *) > > Quake.Define(mach, "HOST", M3Config.TARGET); > Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); > Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); > > but no installation paths. Most code uses MxConfig AS M3Config. > > I see it's used in m3browser as package_root deault, but that can surely > be fixed and it can also be specified on the command line. > Same in m3tohtml. So why is it needed? > > One obvious way to overcome Peter's problem would of course be > to pass a parameter block to quake when building ("m3config-overrides"?). > Better perhaps to get rid of these paths. > > Olaf > > Quoting Peter Eiserloh : > > > Hi Jay, > > > > Do you know of any way to tell the build system that the > > final installation directory is located in one place, but > > that the software is to actually be shipped (temporarily) > > to a staging directory. > > > > Specifically, libm3/src/config contains a m3makefile that > > derives the M3Config interface, containing a number of > > paths to the installation root directory. > > > > This is the normal situation for most people, but I am > > installing to a temporary directory, for packaging purposes. > > The packaging software later installs the package into > > the correct location. > > > > Whenever I build the system, M3Config always contains > > the paths to my staging area. > > > > I would like some way of specifying to the build system > > that the final (or real) installation root is one thing, > > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh | > > +--------------------------------------------------------+ > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 16 14:57:05 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 14:57:05 +0200 Subject: [M3devel] how to port to new target In-Reply-To: References: Message-ID: <20090716145705.vc4lzxbu8oo8kskk@mail.elegosoft.com> How about updating http://www.opencm3.net/porting.html? This mail will be much more difficult to find later... Olaf Quoting Jay K : > "how to port" > > I know there is a web already but maybe it needs updating. (Maybe > not, basically just one item stricken/reduced). > > > Based on the AMD64_NETBSD/OPENBSD work (ChangeLog entry), and /assuming/ > gcc has already been ported, here is a/the specific > current list of files that need visiting for porting: > > > add a file to m3-sys/cminstall/src/config-no-install > m3-sys/m3middle/src/Target.m3 > m3-sys/m3middle/src/Target.i3 (trivial, just add to the list) > m3-libs/m3core/src/runtime/common/Compiler.tmpl (trivial) > > > add m3-libs/m3core/src/C/TARGET/Csetjmp.i3 (redundant with Target.m3) > add m3-libs/m3core/src/C/TARGET/m3makefile (trivial, always the same) > > > all these trivial: > m3-libs/m3core/src/thread.quake > m3-libs/libm3/src/os/POSIX/m3makefile > m3-libs/libm3/src/random/m3makefile > m3-libs/m3core/src/C/Common/m3makefile > m3-libs/m3core/src/Csupport/m3makefile > m3-libs/m3core/src/float/m3makefile > m3-libs/m3core/src/runtime/m3makefile > m3-libs/m3core/src/runtime/POSIX/m3makefile > m3-libs/m3core/src/runtime/common/m3makefile > m3-libs/m3core/src/time/POSIX/m3makefile > m3-libs/m3core/src/unix/Common/m3makefile > > > plus off the top of my head: > scripts/sysinfo.sh -- platform detection using uname etc. > scripts/python/pylib.py -- platform detection and possible changes > to "boot" (redundant with config file sorry) > m3-sys/m3cc/src/m3makefile -- at least add the TARGET => GNU_PLATFORM > mapping for building a cross compiler; sometimes more is needed > m3-sys/m3gdb/src/m3makefile -- ditto > m3-libs/m3core/src/runtime/POSIX/RTSignalC.c > for adding a new processor for Solaris or NetBSD, maybe already portable, > but otherwise this file is highly target specific, though you can > also just fallback and return 0. > I'd rather not put in the fallback, > lest porters don't get a "reminder". > They can always make it so upon being reminded. > (The reminder comes unfortunately late -- when native building > the boot archive on the target platform.) > > > plus some possible revisitation of: > m3-libs/m3core/src/unix/Common but > often just works. > > > Adding a new processor for Darwin is a > little different than other platforms. > Threading is a little different, in a good > way and you might to use Apple's fork of gcc (see > m3cc/m3makefile, look for ARM_DARWIN). > > > In future maybe things go a little different, > like if there are more builtin backends > or stack walkers. (Though I'm hoping for > a fairly portable stack walker using libgcc/libunwind.) > > > It should be possible to significantly reduce > this if you are only adding another processor > for an existing OS, or just another > OS for existing processor. > > > A lot of the checks only depend on endian or OS. > Granted it is not a long list asis. > > > If there is non-Posix non-NT platform, more work. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 16 15:05:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 15:05:58 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I meant to say from what they *were*. I only have to whine non zero > about 'kext' I don't insist or such. What they *are* is fine. I was > agreeing but accidentally disagreed. I thought as much. > - oops (phone) > > On Jul 15, 2009, at 11:37 AM, Jay K wrote: > >> Definitely these should be renamed from what they are. >> Does "kext" bother anyone else, enough to come up with another >> name? kext is the extension for "kernel extensions" on Darwin -- >> drivers. I didn't think of that, but I don't think it matters; there is no program named kext on Darwin, is there? >> Maybe I can get one more change in in the day window. :) Or it can >> be in after the RC, ok. It's a very compatible and fairly desirable >> change, to shorten the symlink chain lengths. If it's easy and won't break anything, go ahead. I'd like to build some packages by the end of this week. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Jul 16 16:39:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Jul 2009 10:39:03 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Message-ID: <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non- optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> A couple of comments on the release notes for 5.8.2:
  • System >> pthread threading is now the default on all >> platforms. The original (fast) M3 user level thread code is >> still there and can be used if necessary (on most platforms). On >> many systems, this allows M3 applications to scale over all >> available hardware processors.
  • >> >> This sounds like it is the original user level threads that allow >> scaling over multiple processors, which I believe is backwards. I >> suggest swapping the second and third sentences be for clarity. >>
  • New data type LONGINT (64 bit integer) on all target >> platforms except Windows (still in the queue).
  • >> >> As I understand it, LONGINT is in Windows too, it just isn't 64 >> bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for > several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least > some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in > source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 16 19:39:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 16 Jul 2009 13:39:29 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090630175228.GA16767@topoi.pooq.com> References: <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> <20090630175228.GA16767@topoi.pooq.com> Message-ID: <20090716173929.GB9087@topoi.pooq.com> On Tue, Jun 30, 2009 at 01:52:28PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: > > > > If it now just works and the problem cannot be reproduced, we should > > leave it that way. I wouldn't invest much time on chasing down such > > a spurious error now. > > OK. I'll take a look at installation instructions for some of the other > packages, such as the one with Trestle. > > -- hendrik Installed the collection m3gdb from archive cm3-bin-ws-m3gdb-LINUXLIBC6-d5.8.1-RC1.tgz; it installed flawlessly on Debian squeeze (32-bit intel). Did the same for m3gui, had a glitch. It's at the end of the shell log below. I've provided the entire log, starting with untarring the archive, in case you need context. -- hendrik hendrik at notlookedfor:~/cm3/collection-gui$ tar -zxf cm3-bin-ws-gui-LINUXLIBC6-d5.8.1-RC1.tgz hendrik at notlookedfor:~/cm3/collection-gui$ ls cm3-bin-ws-gui-LINUXLIBC6-d5.8.1-RC1.tgz install.sh m3-tools m3-win collection-gui.html m3-comm m3-ui hendrik at notlookedfor:~/cm3/collection-gui$ ./install.sh --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 .M3EXPORTS libm3tcp.so.5 libm3tcp.so libm3tcp.a libm3tcp.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/tcp/src/POSIX TCP.m3 TCPPosix.i3 Herrno.i3 HerrnoC.c IP.m3 IPErrorPosix.m3 TCPExtras.m3 TCPPeer.m3 TCPHack.i3 TCPHackNull.m3 ../src/common => /usr/local/cm3/pkg/tcp/src/common TCP.i3 IP.i3 TCPExtras.i3 TCPPeer.i3 IPError.i3 IPError.m3 StreamRd.i3 StreamRdClass.m3 StreamRdClass.i3 StreamWr.i3 StreamWrClass.i3 StreamWrClass.m3 TCPSpecial.i3 TCPMisc.i3 ConnFD.i3 ConnRW.i3 ConnRW.m3 ConnMsgRW.i3 ConnMsgRW.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/X11R4/LINUXLIBC6 .M3EXPORTS libm3X11R4.so.5 libm3X11R4.a libm3X11R4.m3x .M3WEB ../src/Vanilla => /usr/local/cm3/pkg/X11R4/src/Vanilla XMachine.i3 ../src/Common => /usr/local/cm3/pkg/X11R4/src/Common X.i3 Xatom.i3 Xmbuf.i3 Xct.i3 Xmu.i3 Xrm.i3 Xt.i3 XtC.m3 XtC.i3 XtE.i3 XtE.m3 XtN.i3 XtN.m3 XtR.i3 XtR.m3 Xaw.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/ui/LINUXLIBC6 .M3EXPORTS libm3ui.so.5 libm3ui.a libm3ui.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/ui/LINUXLIBC6 ComplSeq.i3 ComplSeq.m3 ComplSeqRep.i3 STypeMapSeq.m3 STypeMapSeq.i3 STypeMapSeqRep.i3 CompletionSeq.m3 CompletionSeq.i3 CompletionSeqRep.i3 ../src/xvbt => /usr/local/cm3/pkg/ui/src/xvbt Compl.i3 Compl.m3 XExtensions.i3 XExtensions.m3 XImUtil.i3 TrslOnXF.i3 XShm.i3 XClientExt.i3 XPicture.m3 XPicture.i3 XSharedMem.i3 XSharedMem.m3 XPictureFree.m3 XSharedFree.m3 PictureImpl.m3 XClient.m3 XClient.i3 XEventQueue.i3 XEventQueue.m3 XScreenType.i3 XScreenType.m3 XScrollQueue.m3 XScrollQueue.i3 XAtomQueue.m3 XAtomQueue.i3 XMessenger.i3 XMessenger.m3 XPaint.i3 XPaint.m3 XInput.i3 XInput.m3 XProperties.i3 XProperties.m3 XClientF.i3 XClientF.m3 XGC.m3 XGC.i3 XScrnTpRep.i3 XScrnTpRep.m3 XScrnCrsr.i3 XScrnCrsr.m3 XScrnCmap.m3 XScrnCmap.i3 XScrnFont.i3 XScrnFont.m3 XScrnPntOp.i3 XScrnPntOp.m3 XScrnPxmp.m3 XScrnPxmp.i3 XCursors.i3 XConfCtl.i3 XConfCtl.m3 TrestleOnX.i3 TrestleOnX.m3 TrestleOS.m3 ../src/vbt => /usr/local/cm3/pkg/ui/src/vbt Latin1Key.i3 KeyboardKey.i3 Trestle.i3 TrestleComm.i3 VBTTuning.i3 BatchRep.i3 PaintExt.i3 PlttFrnds.m3 PlttFrnds.i3 VBT.m3 VBT.i3 VBTClass.i3 VBTClass.m3 Batch.i3 Batch.m3 PaintPrivate.m3 PaintPrivate.i3 VBTRep.m3 VBTRep.i3 TrestleClass.m3 TrestleClass.i3 ScrnPixmap.m3 ScrnPixmap.i3 ScrnColorMap.i3 ScrnColorMap.m3 BatchUtil.i3 BatchUtil.m3 ScrnCursor.m3 ScrnCursor.i3 ScrnFont.i3 ScrnFont.m3 ScrnPaintOp.i3 ScrnPaintOp.m3 PaintOp.m3 PaintOp.i3 Palette.m3 Palette.i3 Font.i3 Font.m3 Cursor.i3 Cursor.m3 Pixmap.m3 Pixmap.i3 ScreenType.m3 ScreenType.i3 MouseSplit.m3 MouseSplit.i3 MiscDetail.m3 MiscDetail.i3 ../src/split => /usr/local/cm3/pkg/ui/src/split BtnVBTClass.i3 TextVBTClass.i3 BdrVBTClass.i3 STypeMap.i3 ComposeKey.m3 ComposeKey.i3 TranslateVBT.m3 TranslateVBT.i3 DblBufferVBT.i3 DblBufferVBT.m3 DblBufferUtil.m3 DblBufferUtil.i3 BorderedVBT.i3 BorderedVBT.m3 FilterClass.m3 FilterClass.i3 HVSplit.i3 HVSplit.m3 ZSplit.i3 ZSplit.m3 TSplit.i3 TSplit.m3 ButtonVBT.i3 ButtonVBT.m3 MenuBtnVBT.i3 MenuBtnVBT.m3 AnchorBtnVBT.i3 AnchorBtnVBT.m3 PackSplit.m3 PackSplit.i3 ProperSplit.i3 ProperSplit.m3 TextVBT.i3 TextVBT.m3 HVBar.i3 HVBar.m3 HighlightVBT.i3 HighlightVBT.m3 QuickBtnVBT.i3 QuickBtnVBT.m3 RigidVBT.m3 RigidVBT.i3 TextureVBT.i3 TextureVBT.m3 Split.i3 Split.m3 Filter.i3 Filter.m3 TypeInVBT.m3 TypeInVBT.i3 StableVBT.m3 StableVBT.i3 Gray.m3 Gray.i3 TwoTone.m3 TwoTone.i3 JoinedVBT.m3 JoinedVBT.i3 JoinParent.m3 JoinParent.i3 JoinScreen.i3 JoinScreen.m3 JoinCMap.m3 JoinCMap.i3 JoinCursor.i3 JoinCursor.m3 JoinFont.m3 JoinFont.i3 JoinPixmap.i3 JoinPixmap.m3 JoinPaintOp.i3 JoinPaintOp.m3 ETAgent.i3 ETAgent.m3 SelectQueue.m3 SelectQueue.i3 OverlayVBT.m3 OverlayVBT.i3 ../src/trestle => /usr/local/cm3/pkg/ui/src/trestle TrestleOS.i3 Trestle.m3 TrestleImpl.i3 InstallQueue.m3 InstallQueue.i3 DpyFilter.m3 DpyFilter.i3 TrestleGoo.i3 TrestleGoo.m3 InstalledVBT.i3 InstalledVBT.m3 TrestleConf.i3 ../src/picture => /usr/local/cm3/pkg/ui/src/picture Completion.m3 Completion.i3 Picture.m3 Picture.i3 PictureRep.i3 FreeList.mg --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/vbtkit/LINUXLIBC6 .M3EXPORTS libm3vbtkit.so.5 libm3vbtkit.a libm3vbtkit.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/vbtkit/LINUXLIBC6 VBTKitBundle.i3 VBTKitBundle.m3 ../src/lego/POSIX => /usr/local/cm3/pkg/vbtkit/src/lego/POSIX ScrollerVBTClass.m3 ZChassisVBT.m3 ../src/lego => /usr/local/cm3/pkg/vbtkit/src/lego AnchorSplit.i3 AnchorSplit.m3 AnchorHelpSplit.i3 AnchorHelpSplit.m3 AnchorHelpVBT.i3 AnchorHelpVBT.m3 BiFeedbackVBT.i3 BiFeedbackVBT.m3 BooleanVBT.i3 BooleanVBT.m3 ChoiceVBT.m3 ChoiceVBT.i3 FeedbackVBT.m3 FeedbackVBT.i3 FileBrowserVBT.i3 FileBrowserVBT.m3 FlexVBT.i3 FlexVBT.m3 GuardedBtnVBT.i3 GuardedBtnVBT.m3 Image.m3 Image.i3 ListVBT.i3 ListVBT.m3 MarginFeedbackVBT.i3 MarginFeedbackVBT.m3 MenuSwitchVBT.i3 MenuSwitchVBT.m3 MultiFilter.i3 MultiFilter.m3 MultiSplit.i3 MultiSplit.m3 MultiClass.i3 MultiClass.m3 NumericVBT.i3 NumericVBT.m3 OffsetVBT.i3 OffsetVBT.m3 PixmapVBT.i3 PixmapVBT.m3 QuickSwitchVBT.i3 QuickSwitchVBT.m3 ReactivityVBT.i3 ReactivityVBT.m3 ScaleFilter.i3 ScaleFilter.m3 ScrollerVBT.i3 ScrollerVBT.m3 ScrollerVBTClass.i3 Shadow.i3 Shadow.m3 ShadowPaint.i3 ShadowPaint.m3 ShadowedBarVBT.i3 ShadowedBarVBT.m3 ShadowedFeedbackVBT.m3 ShadowedFeedbackVBT.i3 ShadowedVBT.m3 ShadowedVBT.i3 SourceVBT.i3 SourceVBT.m3 SplitterVBT.i3 SplitterVBT.m3 SwitchVBT.i3 SwitchVBT.m3 TrillSwitchVBT.i3 TrillSwitchVBT.m3 VBTKitResources.i3 VBTKitResources.m3 ViewportVBT.i3 ViewportVBT.m3 ZBackgroundVBT.i3 ZBackgroundVBT.m3 ZChassisVBT.i3 ZChildVBT.i3 ZChildVBT.m3 ZGrowVBT.i3 ZGrowVBT.m3 ZMoveVBT.i3 ZMoveVBT.m3 ZSplitUtils.i3 ZSplitUtils.m3 ZTilps.i3 ZTilps.m3 ../src/vbtkitutils/POSIX => /usr/local/cm3/pkg/vbtkit/src/vbtkitutils/POSIX VBTKitEnv.i3 ../src/vbtkitutils => /usr/local/cm3/pkg/vbtkit/src/vbtkitutils AnyEvent.m3 AnyEvent.i3 AutoRepeat.i3 AutoRepeat.m3 LargeCursor.i3 LargeCursor.m3 Pts.i3 Pts.m3 Rsrc.i3 Rsrc.m3 VBTColors.i3 VBTColors.m3 VBTKitEnv.m3 XParam.m3 XParam.i3 XTrestle.i3 XTrestle.m3 ../src/etext => /usr/local/cm3/pkg/vbtkit/src/etext ISOChar.i3 ISOChar.m3 Key.i3 Key.m3 KeyFilter.m3 KeyFilter.i3 KeyTrans.i3 KeyTrans.m3 MTextUnit.i3 MTextUnit.m3 TextEditVBT.i3 TextEditVBT.m3 TextPort.i3 TextPort.m3 TextPortClass.m3 TextPortClass.i3 TypeinVBT.i3 TypeinVBT.m3 TypescriptVBT.i3 TypescriptVBT.m3 IvyModel.m3 IvyModel.i3 EmacsModel.i3 EmacsModel.m3 XtermModel.i3 XtermModel.m3 MacModel.m3 MacModel.i3 ../src/vtext => /usr/local/cm3/pkg/vbtkit/src/vtext VTDef.i3 VTextDef.i3 VText.i3 VText.m3 VT.i3 VT.m3 VTBase.i3 VTBase.m3 VTCaret.m3 VTCaret.i3 VTInterval.i3 VTInterval.m3 VTMarker.i3 VTMarker.m3 VTPounce.m3 VTPounce.i3 VTRd.i3 VTRd.m3 VTReal.i3 VTReal.m3 VTTexture.m3 VTTexture.i3 VTView.i3 VTView.m3 VTVirtual.i3 VTVirtual.m3 VTextRegion.m3 VTextRegion.i3 ../src/mtext => /usr/local/cm3/pkg/vbtkit/src/mtext MText.i3 MText.m3 MTextRd.i3 MTextRd.m3 MTextPrivate.i3 MTextDs.i3 MTextDs.m3 MTextDebug.i3 MTextDebug.m3 ../src/color => /usr/local/cm3/pkg/vbtkit/src/color Color.m3 Color.i3 ColorName.i3 ColorName.m3 ColorNameF.i3 ColorNameTable.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/cmvbt/LINUXLIBC6 .M3EXPORTS libcmvbt.so.5 libcmvbt.a libcmvbt.m3x .M3WEB ../src => /usr/local/cm3/pkg/cmvbt/src IntervalTimer.i3 IntervalTimer.m3 TabVBT.i3 TabVBT.m3 IPTypeinVBT.m3 IPTypeinVBT.i3 FrameVBT.i3 FrameVBT.m3 HoverVBT.i3 HoverVBT.m3 PasswordFont.m3 PasswordFont.i3 GridSplit.i3 GridSplit.m3 TableVBT.i3 TableVBT.m3 SortedTableVBT.m3 SortedTableVBT.i3 AnimateVBT.i3 AnimateVBT.m3 ClockVBT.i3 ClockVBT.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/jvideo/LINUXLIBC6 .M3EXPORTS libjvideo.so.5 libjvideo.a libjvideo.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/jvideo/src/POSIX JVBuffer.i3 JVSink.i3 Jv.i3 Jvs.m3 Jvs.i3 Jva.i3 Jva.m3 JvsProtocol.i3 JvaProtocol.i3 jvprotocol.i3 JvsBuffer.i3 JVFromSource.i3 JVFromSource.m3 JVFromDecomp.m3 JVFromDecomp.i3 JVConverter.m3 JVConverter.i3 JVConverterF.i3 JVDecomp.i3 JVDecomp.m3 JVAudio.i3 JVAudio.m3 JVSinkPool.m3 JVSinkPool.i3 JVDecompPool.i3 JVDecompPool.m3 ../src/POSIX/generic => /usr/local/cm3/pkg/jvideo/src/POSIX/generic JVBuffer.m3 JVSink.m3 Jv.m3 JvsBuffer.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/videovbt/LINUXLIBC6 .M3EXPORTS libvideovbt.so.5 libvideovbt.a libvideovbt.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/videovbt/src/POSIX AudioVBT.m3 VideoVBT.m3 VideoVBTRep.i3 ../src => /usr/local/cm3/pkg/videovbt/src AudioVBT.i3 VideoVBT.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsvbtpixmaps/LINUXLIBC6 .M3EXPORTS libm3formsvbtpixmaps.so.5 libm3formsvbtpixmaps.a libm3formsvbtpixmaps.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/formsvbtpixmaps/LINUXLIBC6 FormsVBTPixmapsBundle.i3 FormsVBTPixmapsBundle.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsvbt/LINUXLIBC6 .M3EXPORTS libm3formsvbt.so.5 libm3formsvbt.a libm3formsvbt.m3x .M3WEB ../src => /usr/local/cm3/pkg/formsvbt/src StubImages.i3 StubImageRd.i3 StubImageRd.m3 StubImageVBT.i3 StubImageVBT.m3 FVTypes.i3 FormsVBT.i3 FormsVBT.m3 FVRuntime.m3 FVRuntime.i3 Manpage.i3 Manpage.m3 Macro.i3 Macro.m3 RefListUtils.i3 RefListUtils.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsview/LINUXLIBC6 .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/formsview/src formsview.m3 . => /usr/local/cm3/pkg/formsview/LINUXLIBC6 formsview --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/man/man1 formsedit.1 . => /usr/local/cm3/pkg/formsedit/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/formsedit/LINUXLIBC6 formseditBundle.i3 formseditBundle.m3 ../src => /usr/local/cm3/pkg/formsedit/src FormsEditVBT.i3 FormsEditVBT.m3 FormsEdit.m3 . => /usr/local/cm3/bin formsedit --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/opengl/LINUXLIBC6 .M3EXPORTS libopengl.so.5 libopengl.a libopengl.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/opengl/src/POSIX GL.i3 GLX.i3 GLu.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/webvbt/LINUXLIBC6 .M3EXPORTS libwebvbt.so.5 libwebvbt.a libwebvbt.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/webvbt/LINUXLIBC6 ResourceBundle.i3 ResourceBundle.m3 CITextElementTbl.i3 CITextElementTbl.m3 TextPortButtonSeq.m3 TextPortButtonSeq.i3 TextPortButtonSeqRep.i3 ../src => /usr/local/cm3/pkg/webvbt/src CIText.m3 CIText.i3 Element.i3 Lexer.i3 Lexer.m3 HTML.i3 HTML.m3 HTMLParser.m3 HTMLVBT.i3 HTMLVBT.m3 HTMLVBTG.m3 HTMLVBTG.i3 HTMLVBTGRep.i3 Images.m3 Images.i3 ImageUtils.i3 ImageUtils.m3 Oblet.i3 SimpleWeb.m3 SimpleWeb.i3 URLCache.i3 URLCache.m3 WebVBT.i3 WebVBT.m3 HTMLVBTText.i3 HTMLVBTText.m3 TextPortButton.i3 TextPortButton.m3 TextPortWithButtons.i3 TextPortWithButtons.m3 ../src/oblet => /usr/local/cm3/pkg/webvbt/src/oblet Oblet.m3 ObLibWeb.m3 ObLibWeb.i3 --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. hendrik at notlookedfor:~/cm3/collection-gui$ From jay.krell at cornell.edu Thu Jul 16 20:41:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:41:52 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: Yes. These are subtle but true points. os = cygwin or mingwin or interix or nt but mingwin is really nt, this is clarified below ostype = win32 or posix but this maps directly from os so isn't a multiplicative factor fork = fast or slow or none also maps from os/runtime backend = gcc or integrated gcc backend BITSIZE(LONGINT)==64 integrated backend BITSIZE(LONGINT)==32 I386_CYGWIN (NT386GNU) Posix, slow fork gcc backend, BITSIZE(LONGINT)==64 I386_MINGWIN (NT386MINGNU) Win32, probably no fork (though in reality there some hybrid aspects, intended only for the use of the compiler/linker/etc., intended not to be injected into stuff you build) gcc backend, BITSIZE(LONGINT)==64 I386_INTERIX Posix, fast fork uses gcc backend, BITSIZE(LONGINT)==64 I386_NT (NT386) Win32, no fork integrated backend, BITSIZE(LONGINT)==32 Cygwin hangs in one of the test cases. Mingw had some major problem last I checked like crashing in all gui apps. More combinations than this make sense. You could use the integrated backend with Cygwin or Interix for example. Mingwin, you know, is meant to be NT386 with the gcc backend. Mingwin is not an OS or runtime. Three runtimes: Cygwin, Interix, NT two backends: integrated, gcc therefore 6 combinations of which 4 are named above Consider that integrated backend could be adapted for I386_LINUX, I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... - Jay From: hosking at cs.purdue.edu To: wagner at elegosoft.com Date: Thu, 16 Jul 2009 10:39:03 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non-optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: Quoting "Rodney M. Bates" : A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 20:52:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:52:25 +0000 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: ps: Interix in fact, outside of Modula-3, can use gcc or Visual C++. They have a cc wrapper that translates the command line and calls cl.exe. Not sure if both linkers are available -- you know, because Interix seems to have substantial support for stuff Visual C++ link.exe does not have -- runpath, $origin. As well, Cygwin/mingw/Visual C++ all use the same object file format and to a significant extent can link each other's output. So you can use Visual C++ with Cygwin, gcc without a cygwin dependency. They have/had a gcc -mnocygwin switch, though there is tension between "biarch" vs. "just separate targets". So, actually, in cm3, these are all the same "target", "NT386", just different config files. This was an experiment and I'm still feeling mixed about the results. They way it is constructed leaves it generally pretty easy to construct the combinations that aren't named. You don't have to change cm3 at all, nor I think any m3makefile, just the config file. Well, in the m3makefiles, in m3core, there is deciding on using pthreads or NT threads, since you can use NT threads with Posix cygwin. You know, look at how SOLgnu and SOLsun are implemented -- they are all identical except for the config files. Similar situation but in this case they were broken out into separate targets, and all the target-specific code is /identical/. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elegosoft.com Date: Thu, 16 Jul 2009 18:41:52 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Yes. These are subtle but true points. os = cygwin or mingwin or interix or nt but mingwin is really nt, this is clarified below ostype = win32 or posix but this maps directly from os so isn't a multiplicative factor fork = fast or slow or none also maps from os/runtime backend = gcc or integrated gcc backend BITSIZE(LONGINT)==64 integrated backend BITSIZE(LONGINT)==32 I386_CYGWIN (NT386GNU) Posix, slow fork gcc backend, BITSIZE(LONGINT)==64 I386_MINGWIN (NT386MINGNU) Win32, probably no fork (though in reality there some hybrid aspects, intended only for the use of the compiler/linker/etc., intended not to be injected into stuff you build) gcc backend, BITSIZE(LONGINT)==64 I386_INTERIX Posix, fast fork uses gcc backend, BITSIZE(LONGINT)==64 I386_NT (NT386) Win32, no fork integrated backend, BITSIZE(LONGINT)==32 Cygwin hangs in one of the test cases. Mingw had some major problem last I checked like crashing in all gui apps. More combinations than this make sense. You could use the integrated backend with Cygwin or Interix for example. Mingwin, you know, is meant to be NT386 with the gcc backend. Mingwin is not an OS or runtime. Three runtimes: Cygwin, Interix, NT two backends: integrated, gcc therefore 6 combinations of which 4 are named above Consider that integrated backend could be adapted for I386_LINUX, I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... - Jay From: hosking at cs.purdue.edu To: wagner at elegosoft.com Date: Thu, 16 Jul 2009 10:39:03 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non-optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: Quoting "Rodney M. Bates" : A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 20:54:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:54:59 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword Message-ID: We have some redundancies that are causing me some grief. We have two units called M3ID. They have no overlap, and could be merged into one. "No overlap" doesn't mean they are completely unrelated, but sort of. More bothersome is that m3-sys\m3scanner and m3-tools\m3scan have near duplicate code, in particular the list of tokens and the Classify function. In particular, where people were using libm3\M3Config, there are problems using instead m3quake\MxConfig, because this can bring together the two M3IDs. I was going to replace all uses of M3Config with MxConfig. However to avoid the duplicate M3ID units, I think I'll keep M3Config and MxConfig more like duplicates of each other at least for now, to avoid bringing m3quake into places that have the other M3ID. M3Config is in libm3 and MxConfig is in m3quake. m3quake imports m3middle, which has M3ID. Therefore, if you use M3Config and have your own M3ID, you can't switch to MxConfig without renaming one of the M3IDs. This does occur in m3-tools. C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(25):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): TK = C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(360): END Classify; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.i3(12):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.m3(17):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T = - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 21:08:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 19:08:23 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword In-Reply-To: References: Message-ID: I might be able to win just by making m3scan/m3id.i3 not public, changing Module to module in the m3makefile or such. Or renaming it, same thing really. The unit name only occurs twice. I have to verify nobody uses it outside of m3scan though. Keeping MxConfig/M3Config duplicates isn't great, because I have MxConfig importing M3Config's constants, and then M3Config would want to have a Get function that called into MxConfig -- circularity..though the constants are generated and that could be copied instead...not a lot of duplication here in any case but I'll see... - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Thu, 16 Jul 2009 18:54:59 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword We have some redundancies that are causing me some grief. We have two units called M3ID. They have no overlap, and could be merged into one. "No overlap" doesn't mean they are completely unrelated, but sort of. More bothersome is that m3-sys\m3scanner and m3-tools\m3scan have near duplicate code, in particular the list of tokens and the Classify function. In particular, where people were using libm3\M3Config, there are problems using instead m3quake\MxConfig, because this can bring together the two M3IDs. I was going to replace all uses of M3Config with MxConfig. However to avoid the duplicate M3ID units, I think I'll keep M3Config and MxConfig more like duplicates of each other at least for now, to avoid bringing m3quake into places that have the other M3ID. M3Config is in libm3 and MxConfig is in m3quake. m3quake imports m3middle, which has M3ID. Therefore, if you use M3Config and have your own M3ID, you can't switch to MxConfig without renaming one of the M3IDs. This does occur in m3-tools. C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(25):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): TK = C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(360): END Classify; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.i3(12):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.m3(17):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T = - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 16 21:47:13 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 16 Jul 2009 15:47:13 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <4A5E7496.7020308@cox.net> References: <4A5E7496.7020308@cox.net> Message-ID: <20090716194713.GA9452@topoi.pooq.com> On Wed, Jul 15, 2009 at 07:30:14PM -0500, Rodney M. Bates wrote: > A couple of comments on the release notes for 5.8.2: > >
  • System pthread threading is now the default on all > platforms. The original (fast) M3 user level thread code is > still there and can be used if necessary (on most platforms). On > many systems, this allows M3 applications to scale over all > available hardware processors.
  • > > This sounds like it is the original user level threads that allow > scaling over multiple processors, which I believe is backwards. > I suggest swapping the second and third sentences be for clarity. Actiually. the second sentence won't really work if it's moved to the start, since it seems to launch from the first one. Some rewording may be necessary as well as swapping. -- hendrik From jay.krell at cornell.edu Thu Jul 16 22:36:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 20:36:42 +0000 Subject: [M3devel] M3Config Message-ID: So..I was wondering..what were the original authors thinking? And there was that comment about the file containing the data upon install. Which seemed wrong to me. They were probably thinking of the way 3.6 was packaged and distributed -- everyone built the system from source, upon building m3build/m3ship from C and m3 from assembly. That isn't a bad model, but we probably want both. There are at least three times the paths can be computed/recorded: 1) when you build libm3 2) when you install libm3 #1 and #2 may or may not be close in time and have the same result. 3) by parsing cm3.cfg as needed #2 is more efficient than #3 and matches the old code, but #3 is how I left it, probably ok. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 23:01:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 21:01:03 +0000 Subject: [M3devel] comment in Xmacro.m3 questioning correctness? Message-ID: C:\dev2\cm3.2\m3-ui\motif\src\Xmacro.m3(24): (* does this work on big-endian machines?? *) (*-----------------*) PROCEDURE CharVal(value:CHAR):Xt.ArgVal= BEGIN RETURN LOOPHOLE (ORD (value), Xt.ArgVal); (* does this work on big-endian machines?? *) END CharVal; The code is ok? Otherwise I can write it in portable C.. But I suspect it is ok and we can just strike the comment. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 09:40:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 07:40:07 +0000 Subject: [M3devel] suggest removing version numbers from library names Message-ID: versioning dynamic libraries/shared objects We do, like Darwin: libfoo.5.dylib symlink libfoo.5.2.dylib symlink libfoo.dylib actual file others: libfoo.so.5 symlink libfoo.so as are the conventions. (HP-UX I think just .sa instead of .so.) (NT: Just foo.dll.) I understand the point of this. I may be heretical and lazy, but I am not (entirely) ignorant. :) I suggest that maybe compatibility ("binary" *and* behavioral) and managing version numbers is too difficult, not worth it, that instead programs carry their dependencies with them, and that we just have: libfoo.dylib libfoo.so I further suggest, though it is independent, that we move the lib directory contents into bin. That makes "movement" or "relocation" just slightly easier. I further suggest that most people only consider "binary" compatibility, the parameter order and types of functions, the layout of structs, which is already maybe too difficult, and once one realizes that compatibility includes behavior, the problem is even much larger. I acknowledge that if everyone took this approach, the result would not be great. I assert that carrying dependencies with you eliminates much of the point of dynamic linking, but not all -- you still share among the contents of the same bin directory, code presumably all built around the same time and/or against the same interfaces. If all of the above is rejected, I assert at least that we should have the major.minor version number in the above names derive directly from the checked in version file, that they become 5.8 for this release on Darwin. Oh, hm. We actually aren't following the conventions. I should check if this is an accidental regression. On Birch I see a mix, of no version, three part version, two part version, though three part extension seems most common. Sometimes versions occur in inconsistent places. /usr/lib/libdbus-1.so.3@ /usr/lib/libdbus-1.so.3.2.0 /usr/lib/libdrvproxy.so@ /usr/lib/libdrvproxy.so.2@ /usr/lib/libdrvproxy.so.2.1.15 /usr/lib/libdb-4.2.so /usr/lib/libdb-4.3.so /usr/lib/libdb-4.4.so /usr/lib/libc.a /usr/lib/libc.so /usr/lib/libform.a /usr/lib/libform.so@ /usr/lib/libform.so.5@ /usr/lib/libform.so.5.5 /usr/lib/libcurl.so.3@ /usr/lib/libcurl.so.3.0.0 /usr/lib/libXt.a /usr/lib/libXt.so.6@ /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 /usr/lib/libpython2.4.so@ /usr/lib/libpython2.4.so.1.0 /usr/lib/libpython2.4.so.1@ /usr/lib/libfreetype.a /usr/lib/libfreetype.la (Yes, I've heard of libtool.) /usr/lib/libfreetype.so@ /usr/lib/libfreetype.so.6@ /usr/lib/libfreetype.so.6.3.10 % more /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-x86- 64.so.2 ) ) % ls /lib/libc* /lib/libc.so.6@ etc. so I amend the previous to 5.8.1 on Linux also, and check what other systems do. But really, the first suggestion -- no versions. I wouldn't mind dropping the "lib" prefix but I think that breaks the static vs. dynamic probing that occurs on Darwin and maybe others. Though we do our own thing on Windows with Modula-3 where have foo.lib dynamic foo.lib.sa standalone and the Quake code handles the probing. It should be further noted that various systems including Linux, Solaris, and I believe some of the BSDs have yet another versioning mechanism in use, where, roughly speaking, functions get version names appended to them, but that is not visible at the source level, not even with #defines or #pragmas or inlines, though there is some of that too. Therefore, they can and do rev file names much less frequently than one might expect if one only knew about the use of version numbers in file names. I note this as sort of a counterpoint to the assertion that we should follow the conventions, because, arguably, we aren't fully following them, and probably never will. It'd take inventing new mechanisms to shadow the C mechanisms, and it wouldn't be portable. Realize, $ORIGIN is important to this. NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous. Probably drop support for 4.0. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:28:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:28:58 +0000 Subject: [M3devel] cm3ide crash Message-ID: I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:46:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:46:27 +0000 Subject: [M3devel] FW: cm3ide crash Message-ID: [truncated] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3ide crash Date: Fri, 17 Jul 2009 12:28:58 +0000 I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:46:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:46:02 +0000 Subject: [M3devel] gdb on Darwin Message-ID: Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. AMD64 gives and error that BFD is not supported. x86 skips the critical gdb directory because it isn't supported. If we want this to work, we should probably the importing Apple's fork? Like I did for ARM_DARWIN m3cc? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:47:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:47:26 +0000 Subject: [M3devel] cm3ide crash Message-ID: [truncated again] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3ide crash Date: Fri, 17 Jul 2009 12:28:58 +0000 I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:50:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:50:08 +0000 Subject: [M3devel] cm3ide crash Message-ID: [and again..I'll trim the part that wasn't truncated..] ---- For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 15:48:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 09:48:35 -0400 Subject: [M3devel] cm3ide crash In-Reply-To: References: Message-ID: <60F32660-0DF9-480E-959F-712A51ED0278@cs.purdue.edu> Looks like a null pointer. Sent from my iPhone On Jul 17, 2009, at 8:47 AM, Jay K wrote: > > [truncated again] > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: cm3ide crash > Date: Fri, 17 Jul 2009 12:28:58 +0000 > > > > > > > > > I used cm3ide for a few minutes. > I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when > compiling) it is constructed in a roundabout fashion by running the > code. > See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config > file I usually use. > > Clicking on the examples link: > > (gdb) r > Starting program: /cm3/bin/cm3ide > warning: posix_spawn failed, trying execvp, error: 86 > CAUTION: PKG_USE not defined in cm3.cfg, constructed it from > cm3.cfg path as: /cm3/pkg > CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from > package root as: /cm3/doc > NOTICE: Unable to locate 'examples' folder. > Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 > calling start_browser(http://localhost:3800/) > /Applications/Firefox.app/Contents/MacOS/firefox http://localhost: > 3800/ > starting TCP service > Scanning Packages: Jul 17 05:15... > ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? > scan done: Jul 17 06:27 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > [Switching to process 23997 thread 0x2703] > 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ > Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ > text/Text.m3:16 > #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) > at ../src/os/POSIX/PathnamePosix.m3:65 > #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/ > os/POSIX/FSPosix.m3:243 > #3 0x0000000100042713 in Roots__ScanExamples > (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 > #4 0x0000000100042338 in Roots__ExamplesRootPage > (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, > M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 > #5 0x000000010005abc0 in WebServer__ProcessRequest > (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/ > WebServer.m3:325 > #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) > at ../src/server/TCPServer.m3:116 > #7 0x000000010011b52a in ThreadPThread__RunThread > (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ > ThreadPThread.m3:547 > #8 0x000000010011b1b6 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ > ThreadPThread.m3:523 > #9 0x00007fff82a66deb in _pthread_start () > #10 0x00007fff82a66cad in thread_start () > > There are other problems. > It prompted me for my browser. > > On a Mac, it could offer choices like: > > jaypro:cm3ide jay$ find /Applications | grep -i fox$ > /Applications/Firefox.app/Contents/MacOS/firefox > > jaypro:cm3ide jay$ find /Applications | grep -i fari$ > /Applications/Safari.app/Contents/MacOS/Safari > > if they exist. > Of course I should try Opera and whatever else and report their paths. > > I had to close any existing Firefox, else I got an error that only > one Firefox can run at a time. > The error came from Firefox, not cm3ide. > > For the prompt for editor, I grant there may be too many options to > offer From hosking at cs.purdue.edu Fri Jul 17 15:50:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 09:50:36 -0400 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: Let's avoid pandering to Apple's forks. Better to upgrade to FSF sources that (eventually) should catch up. Sent from my iPhone On Jul 17, 2009, at 8:46 AM, Jay K wrote: > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. > AMD64 gives and error that BFD is not supported. > x86 skips the critical gdb directory because it isn't supported. > > If we want this to work, we should probably the importing Apple's > fork? > Like I did for ARM_DARWIN m3cc? > > - Jay > > > From wagner at elegosoft.com Fri Jul 17 18:51:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 18:51:25 +0200 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Well, it would be great if somebody could (a) provide a short update for the release notes regarding LONGINT and (b) put this into two or three paragraphs (perhaps in their own document) that ordinary users may understand and want to know Olaf Quoting Jay K : > > ps: Interix in fact, outside of Modula-3, can use gcc or Visual C++. > > They have a cc wrapper that translates the command line and calls cl.exe. > > Not sure if both linkers are available -- you know, because Interix > seems to have > > substantial support for stuff Visual C++ link.exe does not have -- > runpath, $origin. > > > > > > As well, Cygwin/mingw/Visual C++ all use the same object file format and > > to a significant extent can link each other's output. > > So you can use Visual C++ with Cygwin, gcc without a cygwin dependency. > > They have/had a gcc -mnocygwin switch, though there is tension > > between "biarch" vs. "just separate targets". > > > > > > So, actually, in cm3, these are all the same "target", "NT386", just > different config files. > > This was an experiment and I'm still feeling mixed about the results. > > > > They way it is constructed leaves it generally pretty easy to > construct the combinations > > that aren't named. You don't have to change cm3 at all, nor I think > any m3makefile, > > just the config file. Well, in the m3makefiles, in m3core, there is > deciding on > > using pthreads or NT threads, since you can use NT threads with Posix cygwin. > > > > > > You know, look at how SOLgnu and SOLsun are implemented -- they are > all identical > > except for the config files. Similar situation but in this case they > were broken > > out into separate targets, and all the target-specific code is /identical/. > > > > > > - Jay > > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Thu, 16 Jul 2009 18:41:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release notes comments > > > > Yes. These are subtle but true points. > > > os = cygwin or mingwin or interix or nt > but mingwin is really nt, this is clarified below > ostype = win32 or posix > but this maps directly from os so isn't a multiplicative factor > fork = fast or slow or none > also maps from os/runtime > backend = gcc or integrated > gcc backend BITSIZE(LONGINT)==64 > integrated backend BITSIZE(LONGINT)==32 > > > I386_CYGWIN (NT386GNU) > Posix, slow fork > gcc backend, BITSIZE(LONGINT)==64 > > I386_MINGWIN (NT386MINGNU) > Win32, probably no fork (though in reality there some hybrid > aspects, intended > only for the use of the compiler/linker/etc., intended not to be > injected into stuff you build) > gcc backend, BITSIZE(LONGINT)==64 > > I386_INTERIX > Posix, fast fork > uses gcc backend, BITSIZE(LONGINT)==64 > > I386_NT (NT386) > Win32, no fork > integrated backend, BITSIZE(LONGINT)==32 > > Cygwin hangs in one of the test cases. > Mingw had some major problem last I checked like crashing in all gui apps. > > More combinations than this make sense. > You could use the integrated backend with Cygwin or Interix for example. > Mingwin, you know, is meant to be NT386 with the gcc backend. > Mingwin is not an OS or runtime. > > Three runtimes: Cygwin, Interix, NT > two backends: integrated, gcc > > therefore 6 combinations of which 4 are named above > > Consider that integrated backend could be adapted for I386_LINUX, > I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, > I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... > > - Jay > > > > > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Thu, 16 Jul 2009 10:39:03 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release notes comments > > > > > > Are there any Windows targets using the gcc-based backend? If so > then they will have BITSIZE(LONGINT)=64 too. It is just the > integrated non-optimizing x86 back-end that currently defines > BITSIZE(LONGINT)=32. > > > On 16 Jul 2009, at 02:24, Olaf Wagner wrote: > > Quoting "Rodney M. Bates" : > > > A couple of comments on the release notes for 5.8.2:
  • System > > pthread threading is now the default on all > > platforms. The original (fast) M3 user level thread code is > > still there and can be used if necessary (on most platforms). On > > many systems, this allows M3 applications to scale over all > > available hardware processors.
  • > > > > This sounds like it is the original user level threads that allow > > scaling over multiple processors, which I believe is backwards. I > > suggest swapping the second and third sentences be for clarity. > >
  • New data type LONGINT (64 bit integer) on all target > > platforms except Windows (still in the queue).
  • > > > > As I understand it, LONGINT is in Windows too, it just isn't 64 > > bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:02:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:02:59 +0200 Subject: [M3devel] M3Config In-Reply-To: References: Message-ID: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> Quoting Jay K : > So..I was wondering..what were the original authors thinking? > > And there was that comment about the file containing the data upon install. > > Which seemed wrong to me. > > They were probably thinking of the way 3.6 was packaged and > distributed -- everyone built the system from source, upon building > m3build/m3ship from C and m3 from assembly. > > That isn't a bad model, but we probably want both. > > There are at least three times the paths can be computed/recorded: > > 1) when you build libm3 > 2) when you install libm3 > #1 and #2 may or may not be close in time and have the same result. > 3) by parsing cm3.cfg as needed > > #2 is more efficient than #3 and matches the old code, but #3 is how > I left it, probably ok. I'd prefer that, too. I take it that you've changed the code correspondingly and we should move the RC2 tag? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:07:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:07:10 +0200 Subject: [M3devel] FW: cm3ide crash In-Reply-To: References: Message-ID: <20090717190710.deb46kibk4k8w40w@mail.elegosoft.com> Can anybody fix that crash? It's probably just a missing text or other NIL pointer (missing examples)... Olaf Quoting Jay K : > I used cm3ide for a few minutes. > I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when > compiling) it is constructed in a roundabout fashion by running the > code. > See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config > file I usually use. > > Clicking on the examples link: > > (gdb) r > Starting program: /cm3/bin/cm3ide > warning: posix_spawn failed, trying execvp, error: 86 > CAUTION: PKG_USE not defined in cm3.cfg, constructed it from > cm3.cfg path as: /cm3/pkg > CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from > package root as: /cm3/doc > NOTICE: Unable to locate 'examples' folder. > Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 > calling start_browser(http://localhost:3800/) > /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ > starting TCP service > Scanning Packages: Jul 17 05:15... > ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? > scan done: Jul 17 06:27 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > [Switching to process 23997 thread 0x2703] > 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at > ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at > ../src/text/Text.m3:16 > #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at > ../src/os/POSIX/PathnamePosix.m3:65 > #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at > ../src/os/POSIX/FSPosix.m3:243 > #3 0x0000000100042713 in Roots__ScanExamples > (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 > #4 0x0000000100042338 in Roots__ExamplesRootPage > (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, > M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 > #5 0x000000010005abc0 in WebServer__ProcessRequest > (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at > ../src/misc/WebServer.m3:325 > #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at > ../src/server/TCPServer.m3:116 > #7 0x000000010011b52a in ThreadPThread__RunThread > (M3_CgoaiZ_me=0x100d02270) at > ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x000000010011b1b6 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x100d02270) at > ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x00007fff82a66deb in _pthread_start () > #10 0x00007fff82a66cad in thread_start () -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:14:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:14:06 +0200 Subject: [M3devel] suggest removing version numbers from library names In-Reply-To: References: Message-ID: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> I think ELF dynamic linkers actually understand just one version number (but may be wrong there). If this is correct, we should probably limit our numbers to that, too. The interesting question is, who is going to increase the number of a dynamic library based on an incompatible change? And can that even be done, or are all the numbers fixed in the config files? I wouldn't be against removing unused complexity. As for moving all libs to bin, I'd postpone that after the release and a perhaps controverse discussion. Olaf Quoting Jay K : > > versioning dynamic libraries/shared objects > > > We do, like > > > Darwin: > libfoo.5.dylib symlink > libfoo.5.2.dylib symlink > libfoo.dylib actual file > > > > others: > libfoo.so.5 symlink > libfoo.so > > > > > > as are the conventions. > > > > (HP-UX I think just .sa instead of .so.) > > (NT: Just foo.dll.) > > > > > I understand the point of this. > I may be heretical and lazy, but I am not (entirely) ignorant. :) > > > > > I suggest that maybe compatibility ("binary" *and* behavioral) and > managing version numbers > is too difficult, not worth it, that instead programs carry their > dependencies with > them, and that we just have: > > > > > libfoo.dylib > libfoo.so > > > > > I further suggest, though it is independent, > that we move the lib directory contents into bin. > That makes "movement" or "relocation" just slightly easier. > > > > > > I further suggest that most people only consider "binary" compatibility, > > the parameter order and types of functions, the layout of structs, > > which is already maybe too difficult, and once one realizes that > compatibility > > includes behavior, the problem is even much larger. > > > > > I acknowledge that if everyone took this approach, the result would > not be great. > > > > > I assert that carrying dependencies with you eliminates much of the point > of dynamic linking, but not all -- you still share among the contents of > the same bin directory, code presumably all built around the same time > and/or against the same interfaces. > > > > > > If all of the above is rejected, I assert at least that we should > have the major.minor version number in the above names derive > directly from the checked in version file, that they become 5.8 for this > release on Darwin. > > > > > Oh, hm. We actually aren't following the conventions. > I should check if this is an accidental regression. > > > > > On Birch I see a mix, of no version, three part version, two part version, > though three part extension seems most common. Sometimes versions > occur in inconsistent > places. > > > > > /usr/lib/libdbus-1.so.3@ > /usr/lib/libdbus-1.so.3.2.0 > > > > > /usr/lib/libdrvproxy.so@ > /usr/lib/libdrvproxy.so.2@ > /usr/lib/libdrvproxy.so.2.1.15 > > > /usr/lib/libdb-4.2.so > /usr/lib/libdb-4.3.so > /usr/lib/libdb-4.4.so > > /usr/lib/libc.a /usr/lib/libc.so > > > > > /usr/lib/libform.a > /usr/lib/libform.so@ > /usr/lib/libform.so.5@ > /usr/lib/libform.so.5.5 > > > > > /usr/lib/libcurl.so.3@ > /usr/lib/libcurl.so.3.0.0 > > > > > /usr/lib/libXt.a /usr/lib/libXt.so.6@ > /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 > > > > > /usr/lib/libpython2.4.so@ > > /usr/lib/libpython2.4.so.1.0 > /usr/lib/libpython2.4.so.1@ > > > > > /usr/lib/libfreetype.a > /usr/lib/libfreetype.la (Yes, I've heard of libtool.) > /usr/lib/libfreetype.so@ > /usr/lib/libfreetype.so.6@ > /usr/lib/libfreetype.so.6.3.10 > > > > % more /usr/lib/libc.so > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf64-x86-64) > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > /lib/ld-linux-x86- > 64.so.2 ) ) > > > > % ls /lib/libc* > /lib/libc.so.6@ > > > etc. > > > so I amend the previous to 5.8.1 on Linux also, and check what other > systems do. > > > > > But really, the first suggestion -- no versions. > > > > > I wouldn't mind dropping the "lib" prefix but I think that breaks the > static vs. dynamic probing that occurs on Darwin and maybe others. > Though we do our own thing on Windows with Modula-3 where have > foo.lib dynamic > foo.lib.sa standalone > > > > > and the Quake code handles the probing. > > > > > It should be further noted that various systems including Linux, > Solaris, and I believe > some of the BSDs have yet another versioning mechanism in use, > where, roughly speaking, > functions get version names appended to them, but that is not > visible at the source level, > not even with #defines or #pragmas or inlines, though there is some > of that too. > > > > > Therefore, they can and do rev file names much less frequently than > one might expect > if one only knew about the use of version numbers in file names. > > > > > I note this as sort of a counterpoint to the assertion that we > should follow the conventions, > because, arguably, we aren't fully following them, and probably never will. > It'd take inventing new mechanisms to shadow the C mechanisms, and > it wouldn't be portable. > > > > > > Realize, $ORIGIN is important to this. > > NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous. > > Probably drop support for 4.0. > > > > > > - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Fri Jul 17 19:26:30 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 13:26:30 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Message-ID: <4A607BEF.1E75.00D7.1@scires.com> Olaf: I have read thru the "Release Notes CM3 5.8.2" page and the "CM3 Release Candidate Index" page. Great job putting this together! Here are some comments for your consideration: 1. The section on "Package", particularly the first paragraph, I think is a bit confusing. The CM3IDE documentation includes a lot of information on packages, so perhaps the missing link in this section should reference that documentation. To me, a package is a set of sources that together represent one compilation unit for the purpose of building a library, program, or other assemblage of information (e.g., documentation). Each package resides in a directory (folder), with sources and generated files in subdirectories (sub folders) of the package's folder. In the top-level CM3 source tree, packages are grouped into categories, with each category represented by a subfolder rooted in that top-level, and the packages comprising each category rooted in the category's folder. 2. I presume that we do intend to make NT386 available for this release, even though it says "Not Available Yet". 3. I find the "-bin-min-" and "-bin-core-" terminology a bit confusing. To me, the "core" of something is the "heart" or "minimal" part of it. Would it make more sense to rename "-bin-core-" to "-bin-std-"? Indeed the explanation given for "core" says in one place that it represents a "standard" installation. In another place it is called "package pool". Also, "min" in one place is called the "central installation hierarchy". Suggest we be consistent. To me it makes more sense to have "min" represent the "minimal installation" and "std" the "standard installation" and "all" represents "everything." 4. I don't understand the "-bin-ws-" concept of "precompiled user workspace" and how it would be useful. Please elaborate. 5. All of the instructions seem to apply for UNIX-like environments. We need to augment these to include how to do it on non-Unix environments, such as Windows. For the scripts, like "install.sh", do we intend to provide Windows command/batch files, e.g. "install.cmd" or "install.bat"? 6. When we finally settle on a release name, need to update the names in these instructions, e.g., replace "d5.8.1-RC1" under "Installation Procedure", and "RC1" in other places. 7. "Installation Procedure" step #5, change "shop" to "ship". 8. "In case of problems" step #4, last line, change "volunteers" to "volunteer" and change "his" to "his/her". Hope some of this helps. Thanks for all your work on this!!! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Fri Jul 17 19:26:40 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 17 Jul 2009 10:26:40 -0700 (PDT) Subject: [M3devel] Request web page updates Message-ID: <670632.92136.qm@web56801.mail.re3.yahoo.com> Hi Olaf, Lets try to get the web site into "ship shape", getting ready for visitors coming to check us out, after reading about the latest release. Can your servers handle the Slashdot effect? Anyways, here are a few suggestions. 1 - Downloads: Could you put a link to the tarball for the 5.8.x release canididate (RC2) onto the web server, more specifically on http://opencm3.net/download.html Once, the final version if 5.8.x is released, remove the link to the RCx tarball, in favor of a permanent link to that final release, just like the 5.4 release. 2 - News: (a) It would also be very nice if the "home" or start page brings up "news" items. I always forget to look at the current news page. Actually I just discovered that it is there. (b) You should add a news item promoting the use of the release candidate, to help expose any regressions before the final release. (c) The major changes to the compiler should be listed somewhere, since the last release shown on the download page. Right now the last release indicated is 5.4. There are some snapshots of 5.5, but not final release of 5.5. 3 - About-CM3: The "About CM3" page, should have a section listing all the changes / enhancements to the language that it accepts vice that described in the language reference from Nelson's SPWM3. For example, WIDECHAR, LONGINT are two new primitive types. Also list all the pragmas recognized by the compiler as that is a compiler unique issue. http://opencm3.net/about-cm3.html It should also list all the architectures that are supported by the compiler. These should always reflect those of the latest "release" version of the compiler. 4 - FAQ: Is there a way to get a single page for the FAQ for the FAQ, one that is easy to print? I haven't had the time to look it over yet, so in time, I will be asking "questions", that we may want to add as FAQ items. 5 - ROADMAP: We should have a page on which we record suggestions for changes to the compiler, libraries, and build system. This should capture the long term goals which require thinking and concurrence among the community. Simple things such as bug fixes would not be listed here. These requested changes (and amendments to them), could then be prioritized, and tracked. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Fri Jul 17 19:35:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:35:13 -0400 Subject: [M3devel] M3Config In-Reply-To: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> References: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> Message-ID: On 17 Jul 2009, at 13:02, Olaf Wagner wrote: > Quoting Jay K : > >> So..I was wondering..what were the original authors thinking? This may be lost in the mists of time. Recall that there were originally two implementations of Modula-3: Olivetti's and DEC's. Remnants of both are in CM3. Perhaps this is an artefact of the merge? >> >> And there was that comment about the file containing the data upon >> install From rcoleburn at scires.com Fri Jul 17 19:41:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 13:41:57 -0400 Subject: [M3devel] cm3ide crash In-Reply-To: References: Message-ID: <4A607F8E.1E75.00D7.1@scires.com> Jay: I've not seen the whole of your message yet; I've received multiple truncated copies. Recall that CM3IDE is the open-source version of "Reactor". Reactor was tightly woven into the CM3 4.1 commercial release. During the install process, cm3install actually adjusted the cm3.cfg file to reflect the installation location, location of your preferred browser, preferred editor, etc. I know you don't use cm3install, and you've made changes to the cm3.cfg files, so if some of this stuff isn't going to be there going forward, I need to make adjustments to CM3IDE. When CM3IDE runs, if it doesn't find these variables in the cm3.cfg file, it tries to locate the appropriate stuff, hence the "CAUTION" messages you saw on stdout. In some cases, it asks the same type question that cm3install would have asked about the editor et al, then saves this information in its configuration file located in the user's home folder. Once the info is saved, it won't prompt you for it again. The error you are getting about the examples folder is probably due to you not copying this folder into your CM3 tree. There are README files explaining all this. If you don't have the examples folder, CM3IDE will still function, except you won't be able to build any of the examples. The examples are all pretty neat IMO, and CM3IDE actually builds them in your private workspace, so you can edit the sources and play around with them without affecting anyone else who wants to try out the examples. Each user gets a fresh copy from the examples folder. Not sure about the crash you are reporting, whether it is due to some problem with your cm3.cfg or your installation or just a bug. I don't experience this crash on Windows, but I have not rebuilt CM3IDE against the latest source tree yet. Perhaps a recent change to the source tree has impacted CM3IDE. I'm supposed to go rafting and camping this weekend with my son's Boy Scout troop, so I don't think I'll have much time to work on this problem. If I get back early, I'll try to look at the problem Sunday evening. Regards, Randy Coleburn >>> Jay K 7/17/2009 8:28 AM >>> I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 19:43:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:43:57 -0400 Subject: [M3devel] Lots of errors in latest Tinderbox on Solaris Message-ID: There seems to be something severely broken: Things like: unable to open "/homes/hosking/tmp/cm3/niagara/cm3/pkg/m3quake/ SOLgnu/.M3EXPORTS" for reading file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/ lib /opt/lib unable to open "/scratch/hosking/work/cm3-ws/ niagara-2009-07-17-10-30-05/cm3/m3-tools/cvsup/suplib/ SOLgnu/.M3EXPORTS" for reading ... Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 19:57:20 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:57:20 -0400 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: Message-ID: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> It seems worrisome that m3tohtml is failing. 34147 HTML package report in /var/folders/Q6/ Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report- I386_DARWIN-2009-07-17-06-27-10.html 34148 >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 / Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34149 === 2009-07-17 06:30:30 cm3 package status run done 34150 === 2009-07-17 06:30:30 build HTML package doc in / Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version 34151 34152 34153 *** 34154 NEXT *** runtime error: 34155 *** Segmentation violation - possible attempt to dereference NIL 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/ Text.m3 34157 *** 34158 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes 34160 8316 Abort trap | m3tohtml -dir html $pkgs 34161 >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/ hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34162 === 2009-07-17 06:30:30 m3tohtml run done -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 17 23:34:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 17:34:57 -0400 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> Message-ID: <4A60B629.1E75.00D7.1@scires.com> I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. Regards, Randy Coleburn >>> Tony Hosking 7/17/2009 1:57 PM >>> It seems worrisome that m3tohtml is failing.34147 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34147 ) HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html34148 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34148 ) >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-0634149 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34149 ) === 2009-07-17 06:30:30 cm3 package status run done34150 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34150 ) === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version34151 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34151 ) 34152 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34152 ) 34153 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34153 ) ***34154 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34154 ) NEXT ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#err51 ) *** runtime error:34155 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34155 ) *** Segmentation violation - possible attempt to dereference NIL34156 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34156 ) *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m334157 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34157 ) ***34158 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34158 ) 34159 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34159 ) regression-scripts/defs.sh: line 712: 8315 Broken pipe yes34160 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34160 ) 8316 Abort trap | m3tohtml -dir html $pkgs34161 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34161 ) >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-0634162 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34162 ) === 2009-07-17 06:30:30 m3tohtml run done CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 18 00:56:23 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 17 Jul 2009 18:56:23 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Message-ID: <20090717225623.GA12084@topoi.pooq.com> On Thu, Jul 16, 2009 at 08:24:22AM +0200, Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > > >A couple of comments on the release notes for 5.8.2:
  • System > >pthread threading is now the default on all > > platforms. The original (fast) M3 user level thread code is > > still there and can be used if necessary (on most platforms). On > > many systems, this allows M3 applications to scale over all > > available hardware processors.
  • > > > >This sounds like it is the original user level threads that allow > >scaling over multiple processors, which I believe is backwards. I > >suggest swapping the second and third sentences be for clarity. > >
  • New data type LONGINT (64 bit integer) on all target > > platforms except Windows (still in the queue).
  • > > > >As I understand it, LONGINT is in Windows too, it just isn't 64 > >bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Current information on Modula 3 is still hard to get, Googling 'Modula 3' still give a lot of links to obsolete information. Perhaps I could update the Wikipedia entry to point to http://www.opencm3.net/releng/ as the place to find information on current development? I know it's only there temporarily, but it's always possible to update it when it moves to its permanent place. Uh ... That is the proper place right now, isn't it? If you approve, I'll do it the next time I'm online long enough (which may not be for a few days; I'm travelling). Unless someone beats me to it, of course. (hint, hint) -- hendrik From jay.krell at cornell.edu Sat Jul 18 01:20:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:20:02 +0000 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: <4A60B629.1E75.00D7.1@scires.com> References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> <4A60B629.1E75.00D7.1@scires.com> Message-ID: Ok sorry I think I understand this all much better now and it should work now. Please let's see how the next runs go. - Jay Date: Fri, 17 Jul 2009 17:34:57 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. Regards, Randy Coleburn >>> Tony Hosking 7/17/2009 1:57 PM >>> It seems worrisome that m3tohtml is failing.34147 HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html 34148 >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34149 === 2009-07-17 06:30:30 cm3 package status run done 34150 === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version 34151 34152 34153 *** 34154 NEXT *** runtime error: 34155 *** Segmentation violation - possible attempt to dereference NIL 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m3 34157 *** 34158 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes 34160 8316 Abort trap | m3tohtml -dir html $pkgs 34161 >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34162 === 2009-07-17 06:30:30 m3tohtml run done -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:27:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:27:42 +0000 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: Apple doesn't push up all its changes, I think because they think/know they wouldn't all be accepted. But granted, actually just supporting a target, should be acceptable. Problems may be more like language changes for Mac source compat, though I'd think with flags to turn them off/on, they'd be ok, but that's another point. The lag does seem severe here though. I guess wait for the gdb 7.0 release and then reevaluate? In the meantime, no m3gdb for I386_DARWIN, AMD64_DARWIN. I haven't tried PPC_DARWIN yet. I agree the forking is unfortunate. Even if it is temporary, it seems to go too long. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 17 Jul 2009 09:50:36 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gdb on Darwin > > Let's avoid pandering to Apple's forks. Better to upgrade to FSF > sources that (eventually) should catch up. > > Sent from my iPhone > > On Jul 17, 2009, at 8:46 AM, Jay K wrote: > > > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. > > AMD64 gives and error that BFD is not supported. > > x86 skips the critical gdb directory because it isn't supported. > > > > If we want this to work, we should probably the importing Apple's > > fork? > > Like I did for ARM_DARWIN m3cc? > > > > - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:37:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:37:39 +0000 Subject: [M3devel] suggest removing version numbers from library names In-Reply-To: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> References: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> Message-ID: I think regarding this file name thing, the linker doesn't have to understand anything at all. Granted that it might. You know, just give an "install name", foo.123.3456, just a string, of arbitrary content, and then manage symlinks appropriately. I'm not sure the dynamic linker has any knowledge of their being numbers and ordering. I thought it was just management of symlinks. And then there is some "internal versioning" that goes on. I don't know if that is all in the static linker or some cooperating between the static linker and dynamic linker. The numbers are in the config files yes. But hey, only about two of them now. :) Unix.common and Darwin.common. That has been the case as long as I've been paying close attention. (Mind you, that's shorter than paying passing attention. :) ) (That is, I'd have to go look at 3.x and 4.x to know, I've just seen 5 and 5.2 forever). > The interesting question is, whois going to increase > the number of a dynamic library based onan incompatible change? And, what is an "incompatible change"? I'm not stupid, I know what an "obvious incompatible change" is, but there are many "subtle possibly incompatible changes", such as to suggest nearly any change is incompatible. Thus, why I suggest it is perhaps almost intractable and just give up, rely on $ORIGIN, and don't support much of a "range" of anything. I just watched Theo de Radt (OpenBSD) talk about release engineering. Some interesting relevant points: "release engineering is testing" I thought testing was an ongoing thing. This actually can vary. "X11 is a big mess" (ok, that's not relevant :) ) "OpenBSD aggressively bumps library version numbers" A passing comment that was hard to hear but I believe he said "We don't believe GNU [or what is ELF?] versioning works and don't use it". I /think/ he was reverring to the "internal versioning" but he didn't elaborate. Maybe I just want him to be referring to it so I can write it off without bothering to understand it. :) OpenBSD's basic fix to release engineering and inadequate testing is dogfooding. /Arguably/ we do that too. We at least build the system and run some tests every day. As to "intensive use" of daily builds, that's harder to see. - Jay > Date: Fri, 17 Jul 2009 19:14:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] suggest removing version numbers from library names > > I think ELF dynamic linkers actually understand just one version number > (but may be wrong there). If this is correct, we should probably > limit our numbers to that, too. The interesting question is, who > is going to increase the number of a dynamic library based on > an incompatible change? And can that even be done, or are all the > numbers fixed in the config files? > > I wouldn't be against removing unused complexity. > > As for moving all libs to bin, I'd postpone that after the release > and a perhaps controverse discussion. > > Olaf > > Quoting Jay K : > > > > > versioning dynamic libraries/shared objects > > > > > > We do, like > > > > > > Darwin: > > libfoo.5.dylib symlink > > libfoo.5.2.dylib symlink > > libfoo.dylib actual file > > > > > > > > others: > > libfoo.so.5 symlink > > libfoo.so > > > > > > > > > > > > as are the conventions. > > > > > > > > (HP-UX I think just .sa instead of .so.) > > > > (NT: Just foo.dll.) > > > > > > > > > > I understand the point of this. > > I may be heretical and lazy, but I am not (entirely) ignorant. :) > > > > > > > > > > I suggest that maybe compatibility ("binary" *and* behavioral) and > > managing version numbers > > is too difficult, not worth it, that instead programs carry their > > dependencies with > > them, and that we just have: > > > > > > > > > > libfoo.dylib > > libfoo.so > > > > > > > > > > I further suggest, though it is independent, > > that we move the lib directory contents into bin. > > That makes "movement" or "relocation" just slightly easier. > > > > > > > > > > > > I further suggest that most people only consider "binary" compatibility, > > > > the parameter order and types of functions, the layout of structs, > > > > which is already maybe too difficult, and once one realizes that > > compatibility > > > > includes behavior, the problem is even much larger. > > > > > > > > > > I acknowledge that if everyone took this approach, the result would > > not be great. > > > > > > > > > > I assert that carrying dependencies with you eliminates much of the point > > of dynamic linking, but not all -- you still share among the contents of > > the same bin directory, code presumably all built around the same time > > and/or against the same interfaces. > > > > > > > > > > > > If all of the above is rejected, I assert at least that we should > > have the major.minor version number in the above names derive > > directly from the checked in version file, that they become 5.8 for this > > release on Darwin. > > > > > > > > > > Oh, hm. We actually aren't following the conventions. > > I should check if this is an accidental regression. > > > > > > > > > > On Birch I see a mix, of no version, three part version, two part version, > > though three part extension seems most common. Sometimes versions > > occur in inconsistent > > places. > > > > > > > > > > /usr/lib/libdbus-1.so.3@ > > /usr/lib/libdbus-1.so.3.2.0 > > > > > > > > > > /usr/lib/libdrvproxy.so@ > > /usr/lib/libdrvproxy.so.2@ > > /usr/lib/libdrvproxy.so.2.1.15 > > > > > > /usr/lib/libdb-4.2.so > > /usr/lib/libdb-4.3.so > > /usr/lib/libdb-4.4.so > > > > /usr/lib/libc.a /usr/lib/libc.so > > > > > > > > > > /usr/lib/libform.a > > /usr/lib/libform.so@ > > /usr/lib/libform.so.5@ > > /usr/lib/libform.so.5.5 > > > > > > > > > > /usr/lib/libcurl.so.3@ > > /usr/lib/libcurl.so.3.0.0 > > > > > > > > > > /usr/lib/libXt.a /usr/lib/libXt.so.6@ > > /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 > > > > > > > > > > /usr/lib/libpython2.4.so@ > > > > /usr/lib/libpython2.4.so.1.0 > > /usr/lib/libpython2.4.so.1@ > > > > > > > > > > /usr/lib/libfreetype.a > > /usr/lib/libfreetype.la (Yes, I've heard of libtool.) > > /usr/lib/libfreetype.so@ > > /usr/lib/libfreetype.so.6@ > > /usr/lib/libfreetype.so.6.3.10 > > > > > > > > % more /usr/lib/libc.so > > /* GNU ld script > > Use the shared library, but some functions are only in > > the static library, so try that secondarily. */ > > OUTPUT_FORMAT(elf64-x86-64) > > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > > /lib/ld-linux-x86- > > 64.so.2 ) ) > > > > > > > > % ls /lib/libc* > > /lib/libc.so.6@ > > > > > > etc. > > > > > > so I amend the previous to 5.8.1 on Linux also, and check what other > > systems do. > > > > > > > > > > But really, the first suggestion -- no versions. > > > > > > > > > > I wouldn't mind dropping the "lib" prefix but I think that breaks the > > static vs. dynamic probing that occurs on Darwin and maybe others. > > Though we do our own thing on Windows with Modula-3 where have > > foo.lib dynamic > > foo.lib.sa standalone > > > > > > > > > > and the Quake code handles the probing. > > > > > > > > > > It should be further noted that various systems including Linux, > > Solaris, and I believe > > some of the BSDs have yet another versioning mechanism in use, > > where, roughly speaking, > > functions get version names appended to them, but that is not > > visible at the source level, > > not even with #defines or #pragmas or inlines, though there is some > > of that too. > > > > > > > > > > Therefore, they can and do rev file names much less frequently than > > one might expect > > if one only knew about the use of version numbers in file names. > > > > > > > > > > I note this as sort of a counterpoint to the assertion that we > > should follow the conventions, > > because, arguably, we aren't fully following them, and probably never will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:40:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:40:41 +0000 Subject: [M3devel] cm3ide crash In-Reply-To: <4A607F8E.1E75.00D7.1@scires.com> References: <4A607F8E.1E75.00D7.1@scires.com> Message-ID: I admit I might have increased the problems. I'll try again with my config file fixes. Truncated stuff: There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. And maybe still CodeWarrior, I can maybe get some paths for it if you want. And maybe BBEdit, I can try a trial version. Komodo. In general of course, many. - Jay Date: Fri, 17 Jul 2009 13:41:57 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] cm3ide crash Jay: I've not seen the whole of your message yet; I've received multiple truncated copies. Recall that CM3IDE is the open-source version of "Reactor". Reactor was tightly woven into the CM3 4.1 commercial release. During the install process, cm3install actually adjusted the cm3.cfg file to reflect the installation location, location of your preferred browser, preferred editor, etc. I know you don't use cm3install, and you've made changes to the cm3.cfg files, so if some of this stuff isn't going to be there going forward, I need to make adjustments to CM3IDE. When CM3IDE runs, if it doesn't find these variables in the cm3.cfg file, it tries to locate the appropriate stuff, hence the "CAUTION" messages you saw on stdout. In some cases, it asks the same type question that cm3install would have asked about the editor et al, then saves this information in its configuration file located in the user's home folder. Once the info is saved, it won't prompt you for it again. The error you are getting about the examples folder is probably due to you not copying this folder into your CM3 tree. There are README files explaining all this. If you don't have the examples folder, CM3IDE will still function, except you won't be able to build any of the examples. The examples are all pretty neat IMO, and CM3IDE actually builds them in your private workspace, so you can edit the sources and play around with them without affecting anyone else who wants to try out the examples. Each user gets a fresh copy from the examples folder. Not sure about the crash you are reporting, whether it is due to some problem with your cm3.cfg or your installation or just a bug. I don't experience this crash on Windows, but I have not rebuilt CM3IDE against the latest source tree yet. Perhaps a recent change to the source tree has impacted CM3IDE. I'm supposed to go rafting and camping this weekend with my son's Boy Scout troop, so I don't think I'll have much time to work on this problem. If I get back early, I'll try to look at the problem Sunday evening. Regards, Randy Coleburn >>> Jay K 7/17/2009 8:28 AM >>> I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:43:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:43:38 +0000 Subject: [M3devel] cm3ide crash In-Reply-To: References: <4A607F8E.1E75.00D7.1@scires.com> Message-ID: [That was also truncated, but the direct send to Randy probably won't be..] > From: jay > To: rcoleburn; m3devel > Date: Fri, 17 Jul 2009 23:40:41 +0000 > Subject: Re: [M3devel] cm3ide crash > > I admit I might have increased the problems. I'll try again with my config file fixes. > Truncated stuff: > [deliberate snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 02:47:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 00:47:32 +0000 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> <4A60B629.1E75.00D7.1@scires.com> Message-ID: Oh darn I also forgot about the m3overrides files. Anywhere I added import("m3quake") needs override(ROOT, "m3-sys/m3quake") or such in the m3overrides -- whatever the existing quake users have (e.g. m3-sys/cm3). I can't get to that now. Can anyone else? Else much later today/tonight/tomorrow. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Fri, 17 Jul 2009 23:20:02 +0000 > Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: > > > > > > > > > Ok sorry I think I understand this all much better now and it should work now. Please let's see how the next runs go. > > > > - Jay > > > ________________________________ > > Date: Fri, 17 Jul 2009 17:34:57 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: > > > I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. > > Regards, > > Randy Coleburn > >>>> Tony Hosking 7/17/2009 1:57 PM>>> > > It seems worrisome that m3tohtml is failing. > > 34147 HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html > 34148>>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 > 34149 === 2009-07-17 06:30:30 cm3 package status run done > 34150 === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version > 34151 > 34152 > 34153 *** > 34154 NEXT *** runtime error: > 34155 *** Segmentation violation - possible attempt to dereference NIL > 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m3 > 34157 *** > 34158 > 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes > 34160 8316 Abort trap | m3tohtml -dir html $pkgs > 34161>>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 > 34162 === 2009-07-17 06:30:30 m3tohtml run done > From jay.krell at cornell.edu Sat Jul 18 02:20:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 17 Jul 2009 17:20:07 -0700 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: <03AC38D3-6818-4D1B-9B53-33582010D25B@hotmail.com> Wait a sec actually the problem might be larger here. Apple has its own object and executable format. I think its own static linker. I think a very old fork of gas. We don't care particularly about 'binutils' but it apparently intersects with gdb in bfd. There is investigation to be done but it wouldn't surprise me if this is a large permanent fork. - Jay (phone) On Jul 17, 2009, at 4:27 PM, Jay K wrote: > Apple doesn't push up all its changes, I think because they think/ > know they wouldn't all be accepted. > But granted, actually just supporting a target, should be acceptable. > Problems may be more like language changes for Mac source compat, > though I'd think with flags to turn them off/on, they'd be ok, but > that's another point. > > The lag does seem severe here though. > I guess wait for the gdb 7.0 release and then reevaluate? > In the meantime, no m3gdb for I386_DARWIN, AMD64_DARWIN. > I haven't tried PPC_DARWIN yet. > > I agree the forking is unfortunate. > Even if it is temporary, it seems to go too long. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Fri, 17 Jul 2009 09:50:36 -0400 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] gdb on Darwin > > > > Let's avoid pandering to Apple's forks. Better to upgrade to FSF > > sources that (eventually) should catch up. > > > > Sent from my iPhone > > > > On Jul 17, 2009, at 8:46 AM, Jay K wrote: > > > > > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/ > AMD64. > > > AMD64 gives and error that BFD is not supported. > > > x86 skips the critical gdb directory because it isn't supported. > > > > > > If we want this to work, we should probably the importing Apple's > > > fork? > > > Like I did for ARM_DARWIN m3cc? > > > > > > - Jay > > > > > > > > > From jay.krell at cornell.edu Sat Jul 18 03:55:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 01:55:37 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Message-ID: > Well, it would be great if somebody could > > (a) provide a short update for the release notes regarding LONGINT and > (b) put this into two or three paragraphs (perhaps in their own > document) that ordinary users may understand and want to know > > Olaf There is a new type LONGINT. It is a 64bit signed integer on all platforms except the native NT "NT386" platform. On NT386 is a 32bits, for now, but we would like to fix that. or There is a new type LONGINT. >> Abstractly, it is a signed integer type with at least as many bits as INTEGER. Concretely it is a 64bit signed integer on all platforms except the native NT "NT386" platform. On NT386 is a 32bits, for now, but we would like to fix that. -- end of relnote, begin commentary -- Depending on some philosophy. Personally I adhere to a simpler philosophy where most integer types are of a fixed known size and will never ever change, you might as well encode the size in the name and use just those types -- int8_t, int16_t, in32_t, int64_t or INT8, INT16, INT32, INT64. And then some other types are exactly the same size as a pointer -- ptrdiff_t, size_t, Modula-3 INTEGER -- and will shrink/grow to fit. And there only exists "flat" address spaces. There is the other philosophy that merely states minimum sizes for all the types and an ordering among them, that allows for, say, every integer type to be 64 bits and many other configurations. - Jay From jay.krell at cornell.edu Sat Jul 18 10:25:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 08:25:06 +0000 Subject: [M3devel] hard link commands in quake? Message-ID: Should we keep the hard link commands in quake or not? They've only been there a short time, they were seen to work, and they are no longer used. Perhaps folks will end up wanting them for some reason?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 11:38:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 11:38:21 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <20090717225623.GA12084@topoi.pooq.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <20090717225623.GA12084@topoi.pooq.com> Message-ID: <20090718113821.ojh9fa6lkoko4gkc@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Current information on Modula 3 is still hard to get, Googling 'Modula > 3' still give a lot of links to obsolete information. Perhaps I could > update the Wikipedia entry to point to http://www.opencm3.net/releng/ as > the place to find information on current development? I know it's only > there temporarily, but it's always possible to update it when it moves > to its permanent place. > > Uh ... That is the proper place right now, isn't it? There are currently two domains associated with M3: www.modula3.org (formerly m3.org) www.opencm3.net (cm3 development) These should be used and known. Recently we were able to secure modula3.com, but I'd like to reserve this for other uses. Of course the old elegosoft links still work, too: modula3.elegosoft.com/{cm3,pm3} should be valid. > If you approve, I'll do it the next time I'm online long enough > (which may not be for a few days; I'm travelling). Unless someone beats > me to it, of course. (hint, hint) Just go ahead... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:36:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:36:16 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <4A607BEF.1E75.00D7.1@scires.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> Message-ID: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Quoting Randy Coleburn : > 1. The section on "Package", particularly the first paragraph, I > think is a bit confusing. The CM3IDE documentation includes a lot > of information on packages, so perhaps the missing link in this > section should reference that documentation. To me, a package is a > set of sources that together represent one compilation unit for the > purpose of building a library, program, or other assemblage of > information (e.g., documentation). Each package resides in a > directory (folder), with sources and generated files in > subdirectories (sub folders) of the package's folder. In the > top-level CM3 source tree, packages are grouped into categories, > with each category represented by a subfolder rooted in that > top-level, and the packages comprising each category rooted in the > category's folder. Actually that part was copied from an older document by Neels, I think. What's the exact link you have i nmnd? http://www.opencm3.net/doc/help/cm3/packages.html? > 2. I presume that we do intend to make NT386 available for this > release, even though it says "Not Available Yet". Yes. Nobody has built any though. You or Jay may want to do that once we have fixed RC2. > 3. I find the "-bin-min-" and "-bin-core-" terminology a bit > confusing. To me, the "core" of something is the "heart" or > "minimal" part of it. Would it make more sense to rename > "-bin-core-" to "-bin-std-"? Indeed the explanation given for > "core" says in one place that it represents a "standard" > installation. In another place it is called "package pool". Also, > "min" in one place is called the "central installation hierarchy". > Suggest we be consistent. To me it makes more sense to have "min" > represent the "minimal installation" and "std" the "standard > installation" and "all" represents "everything." I grant it may be confusing, but am somewhat reluctant to change that now. It's legacy from the older package collections (all defined in pkginfo.txt) and used by a lot of scripts, IIRC. We have a `standard' collection there, too, but that has grown to `all' in the meantime. `min' was always the smallest possible installation (just cm3, m3core, libm3). `core' could be thought of as the packages needed to build the system itself (plus some useful libraries :-/). You're right, it's not really accurate, but I'd rather not change it for this release. Anybody's welcome to do it afterwards. Perhaps we could improve the explanation on the web pages? > 4. I don't understand the "-bin-ws-" concept of "precompiled user > workspace" and how it would be useful. Please elaborate. Copied from a mail I sent to Jay some weeks ago: ---- The idea was to reduce the number of packages, as M3 does not really support the separation of source and derived files for binary packages. So why not just enrich the source with just the products needed for shipping? This is sort of the smallest supported _M3_-binary package. Both system-dependent source and binary packages can be based on the same collection of ws packages. Traditionally CM3 offered only sources packages except for the minimal installation archive. There were lots of problems with o people understanding how to compile the source and o actual compilation errors due to miscellaneous causes People wanted something that is easy to install (without using lots of complex scripts). So I extended the standard cm3 builder so it can be used for such an installation. These are exactly the ws archives. M3 source and derived files which are needed for shipping an M3 package, but not more. I found that rather nice. ---- Does that make it clearer? > 5. All of the instructions seem to apply for UNIX-like > environments. We need to augment these to include how to do it on > non-Unix environments, such as Windows. For the scripts, like > "install.sh", do we intend to provide Windows command/batch files, > e.g. "install.cmd" or "install.bat"? Yes, I haven't spent much thought on Windows until now. I hoped that you or Jay will do that. Of course I've also overseen the install.cmd scripts for Windows :-/ Should we use cmd or bat? Could somebody quickly provide the equivalent of this loop, so that I can automate it? ---- #!/bin/sh HERE=`pwd` for p in m3-win/import-libs ... m3-comm/tcp; do cd $p cm3 -ship ${SHIPARGS} cd $HERE done ---- > 6. When we finally settle on a release name, need to update the > names in these instructions, e.g., replace "d5.8.1-RC1" under > "Installation Procedure", and "RC1" in other places. Much of the RCs is generated, but we'll probably have to replace some manually. > 7. "Installation Procedure" step #5, change "shop" to "ship". done > 8. "In case of problems" step #4, last line, change "volunteers" to > "volunteer" and change "his" to "his/her". done > Hope some of this helps. Sure. Updates are online and checked-in. Thanks for the comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:45:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:45:24 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090716173929.GB9087@topoi.pooq.com> References: <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> <20090630175228.GA16767@topoi.pooq.com> <20090716173929.GB9087@topoi.pooq.com> Message-ID: <20090718124524.4p91p1m0e8sw4404@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Jun 30, 2009 at 01:52:28PM -0400, hendrik at topoi.pooq.com wrote: >> On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: >> > >> > If it now just works and the problem cannot be reproduced, we should >> > leave it that way. I wouldn't invest much time on chasing down such >> > a spurious error now. >> >> OK. I'll take a look at installation instructions for some of the other >> packages, such as the one with Trestle. >> >> -- hendrik > > Installed the collection m3gdb from archive > cm3-bin-ws-m3gdb-LINUXLIBC6-d5.8.1-RC1.tgz; it installed flawlessly on > Debian squeeze (32-bit intel). > > Did the same for m3gui, had a glitch. It's at the end of the shell log > below. I've provided the entire log, starting with untarring the > archive, in case you need context. I think that's already fixed and should not occur with the next archive set. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:52:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:52:27 +0200 Subject: [M3devel] Request web page updates In-Reply-To: <670632.92136.qm@web56801.mail.re3.yahoo.com> References: <670632.92136.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090718125227.utf4lmyigwss0s48@mail.elegosoft.com> Hi Peter, thanks for the concrete suggestions. There are no RC2 packages yet, because there have been changes and further problems. Of course we'll have to adapt the web presentation, but I'd like to wait until the packages are there. If you like, you can already make changes to the pages checked-in to cm3/www though. www.opencm3.net/releng is not publicly linked by intention yet. I'm not sure if we can release RC2 this weekend, and I'm really busy during the week. I'll provide a status list from my point of view to better coordinate things. Thanks again, Olaf Quoting Peter Eiserloh : > Hi Olaf, > > Lets try to get the web site into "ship shape", getting ready > for visitors coming to check us out, after reading about the > latest release. Can your servers handle the Slashdot effect? > > Anyways, here are a few suggestions. > > > 1 - Downloads: Could you put a link to the tarball for the > 5.8.x release canididate (RC2) onto the web server, more > specifically on > > http://opencm3.net/download.html > > Once, the final version if 5.8.x is released, remove the link to the > RCx tarball, in favor of a permanent link to that final release, > just like the 5.4 release. > > > 2 - News: (a) It would also be very nice if the "home" or start page > brings up "news" items. I always forget to look at the > current news page. Actually I just discovered that it is > there. > > (b) You should add a news item promoting the use of the release > candidate, to help expose any regressions before the final > release. > > (c) The major changes to the compiler should be listed > somewhere, since the last release shown on the download > page. Right now the last release indicated is 5.4. > There are some snapshots of 5.5, but not final release > of 5.5. > > > 3 - About-CM3: The "About CM3" page, should have a section > listing all the changes / enhancements to the language that > it accepts vice that described in the language reference > from Nelson's SPWM3. > > For example, WIDECHAR, LONGINT are two new primitive types. > > Also list all the pragmas recognized by the compiler as > that is a compiler unique issue. > > http://opencm3.net/about-cm3.html > > It should also list all the architectures that are supported > by the compiler. These should always reflect those of the > latest "release" version of the compiler. > > > 4 - FAQ: Is there a way to get a single page for the FAQ > for the FAQ, one that is easy to print? > > I haven't had the time to look it over yet, so in time, > I will be asking "questions", that we may want to add > as FAQ items. > > > 5 - ROADMAP: We should have a page on which we record > suggestions for changes to the compiler, libraries, and > build system. This should capture the long term goals > which require thinking and concurrence among the community. > Simple things such as bug fixes would not be listed here. > > These requested changes (and amendments to them), could > then be prioritized, and tracked. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 13:42:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 11:42:29 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: > > 4. I don't understand the "-bin-ws-" concept of "precompiled user > > workspace" and how it would be useful. Please elaborate. > > Copied from a mail I sent to Jay some weeks ago: I actually still don't understand that. Archiving up the installed form includes source. What is the value of doing the ship/directory reorganization upon install? However, it is kind of a step toward a distribution that includes assembly for everything and then assemble, c compile, link, and ship on the target. (You might even use autoconf/libtool, though their powers will be severely constrained by the presence of assembly.) And such a distribution is easily cross built for all targets in one fell automated swoop on one host, good, valuable that way. > Yes, I haven't spent much thought on Windows until now. I hoped that > you or Jay will do that. Of course I've also overseen the install.cmd > scripts for Windows :-/ Should we use cmd or bat? Could somebody > quickly provide the equivalent of this loop, so that I can > automate it? There are recent builds on http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip as well as: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PPC_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PPC_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PPC_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PPC_LINUX-d5.8.1.tar.gz etc. sorry.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 13:56:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 13:56:25 +0200 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> Quoting Jay K : >> > 4. I don't understand the "-bin-ws-" concept of "precompiled user >> > workspace" and how it would be useful. Please elaborate. >> >> Copied from a mail I sent to Jay some weeks ago: > > I actually still don't understand that. Strange. > Archiving up the installed form includes source. No, only partial sources (historically the IFs, in CM3 modules, too -- but no makefiles for example). > What is the value of doing the ship/directory reorganization upon install? Easiest way to combine complete _usable_ source and binary products. > However, it is kind of a step toward a distribution that includes assembly > for everything and then assemble, c compile, link, and ship on the target. > (You might even use autoconf/libtool, though their powers will be severely > constrained by the presence of assembly.) > And such a distribution is easily cross built for all targets in one > fell automated > swoop on one host, good, valuable that way. > >> Yes, I haven't spent much thought on Windows until now. I hoped that >> you or Jay will do that. Of course I've also overseen the install.cmd >> scripts for Windows :-/ Should we use cmd or bat? Could somebody >> quickly provide the equivalent of this loop, so that I can >> automate it? > There are recent builds on > http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > > as well as: > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb [...] > > sorry.. That's not what we're talking about. We're talking about installation archives for Windows for RC2 as they are described in the release notes. There are none. I can build them myself, but then it will take another couple of weeks. No hurry needed though, as we haven't fixed RC2 yet. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 14:12:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:12:48 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> Message-ID: "usable source" as in editable and then rebuildable? Ok, that I see. > No, only partial sources (historically the IFs, in CM3 modules, too -- I didn't realize the history but I did notice the option and considered it to shrink the distributions, but the source is useful for debugging. > but no makefiles for example). To serve as examples and to make it buildable? Ok. Then I like it. :) Like, it is gentler than having newbies use cvs, and gets the versions that match their binaries. Change the release notes? Well, er, um, I guess the "ws" form on Windows might be nice too. You can say this: install.cmd: SetLocal set root=%~dp0 set pkgs= set pkgs=%pkgs% m3-sys/cm3 set pkgs=%pkgs% m3-sys/m3quake set pkgs=%pkgs% m3-libs/m3core etc. for %%a in (%pkgs%) do call :F1 %%a || exit /b 1 goto :eof :F1 set b=%1 rem replace forward slashes with backward slashes set b=%b:/=\% cd %root%\%b% || exit /b 1 cm3 -ship || exit /b 1 goto :eof There is an implied label :eof at the end of files. "goto :eof" is how you "return". You can also create pkgs.txt: m3-sys/cm3 m3-sys/m3quake etc. install.cmd SetLocal set root=%~dp0 for /f %%a in (%root%\pkgs.txt) do call :F1 %%a || exit /b 1 goto :eof :F1 set b=%1 rem replace forward slashes with backward slashes set b=%b:/=\% cd %root%\%b% || exit /b 1 cm3 -ship || exit /b 1 goto :eof I guess ideally pkgs.txt is identical files across all platforms, though maybe alter the newlines, and then you write install.sh and install.cmd that are constant and look for pkgs.txt "next to" them? This "advanced" sort of cmd won't work on Win9x but it should work pretty far back on NT like to 4.0 or maybe 3.51. For Win9x compat, and actual even for sanity, you'd might want to consider install.js or install.vbs. .js is a pretty ok language and .cmd is awful after a few lines. I guess I'll do this -- install.cmd + pkgs.txt. - Jay > Date: Sat, 18 Jul 2009 13:56:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Release notes comments > > Quoting Jay K : > > >> > 4. I don't understand the "-bin-ws-" concept of "precompiled user > >> > workspace" and how it would be useful. Please elaborate. > >> > >> Copied from a mail I sent to Jay some weeks ago: > > > > I actually still don't understand that. > Strange. > > > Archiving up the installed form includes source. > No, only partial sources (historically the IFs, in CM3 modules, too -- > but no makefiles for example). > > > What is the value of doing the ship/directory reorganization upon install? > Easiest way to combine complete _usable_ source and binary products. > > > However, it is kind of a step toward a distribution that includes assembly > > for everything and then assemble, c compile, link, and ship on the target. > > (You might even use autoconf/libtool, though their powers will be severely > > constrained by the presence of assembly.) > > And such a distribution is easily cross built for all targets in one > > fell automated > > swoop on one host, good, valuable that way. > > > >> Yes, I haven't spent much thought on Windows until now. I hoped that > >> you or Jay will do that. Of course I've also overseen the install.cmd > >> scripts for Windows :-/ Should we use cmd or bat? Could somebody > >> quickly provide the equivalent of this loop, so that I can > >> automate it? > > > There are recent builds on > > http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. > > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > > > > as well as: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb > [...] > > > > sorry.. > > That's not what we're talking about. We're talking about installation > archives for Windows for RC2 as they are described in the release > notes. There are none. > > I can build them myself, but then it will take another couple of weeks. > No hurry needed though, as we haven't fixed RC2 yet. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:17:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:17:03 +0000 Subject: [M3devel] crossing from 64bit to 32bit? Message-ID: There appears to be a problem cross building from a 64bit host to a 32bit target. For example host=AMD64_DARWIN, target=PPC_DARWIN: == package /dev2/cm3/m3-sys/m3back == +++ /cm3/bin/cm3 -build -override -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=2009-05-16 @M3novm -boot -keep +++ --- building in PPC_DARWIN --- "../src/M3x86.m3", line 1549: set domain too large "../src/M3x86.m3", line 1570: set domain too large *** *** runtime error: *** An array subscript was out of range. *** file "../src/exprs/SetExpr.m3", line 701 *** I guess I should look at it.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 14:18:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 14:18:22 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king Message-ID: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> We really need to use some tools to help us keep (or gain?) control of the release process. Trac has been available for more than a year, but nobody has actively used it. Maybe this is a good time now :-) I've started by sketching a roadmap with RC2, 5.8 and 5.9. See here: https://projects.elego.de/cm3/roadmap Please add all the problems that were just reported via mail to the trac database with `new ticket': https://projects.elego.de/cm3/newticket. I've tried it for the cm3ide crash (ticket 1002); it seems to work fine. Some older bug reports are also still unresolved, but we can check them later. It would also be helpful if all active developers had personalized access and would help updating the tickets and the WiKi. Please send mail to admins(at)elego.de to obtain an account from Michael or Joffrey. Please let's use this; I'm afraid we'll lose control without it. It also has the advantage that the HTTP GUI is accessible from the customer network I'm usually working on (while everything else is blocked). Thanks in advance for your cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 14:17:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:17:28 +0000 Subject: [M3devel] crossing from 64bit to 32bit? Message-ID: (same thing crossing to I386_DARWIN) From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: crossing from 64bit to 32bit? Date: Sat, 18 Jul 2009 12:17:03 +0000 There appears to be a problem cross building from a 64bit host to a 32bit target. For example host=AMD64_DARWIN, target=PPC_DARWIN: == package /dev2/cm3/m3-sys/m3back == +++ /cm3/bin/cm3 -build -override -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=2009-05-16 @M3novm -boot -keep +++ --- building in PPC_DARWIN --- "../src/M3x86.m3", line 1549: set domain too large "../src/M3x86.m3", line 1570: set domain too large *** *** runtime error: *** An array subscript was out of range. *** file "../src/exprs/SetExpr.m3", line 701 *** I guess I should look at it.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:27:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:27:46 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: My opinion on some of these: cm3ide crash (NIL pointer?) #1002 probably fixed but needs retesting m3tohtml crash probably fixed but needs retesting broken m3overrides probably fixed but need to wait for Tinderbox to confirm I can migrate more of them to the one master, but that's not required. And there are some variations that need to be preserved, so it has to be all human reviewed. remove/simplify dynamic library version numbering? Can be left alone. I advocate removing the versions entirely. However the "complexity" here is very hidden anyway. m3gdb doesn't build on Darwin I think we punt on this for this release. Just update the distribution building to skip it. I think the fix is probably to import Apple's fork. I don't like it either, but it's probably the "best" way (short of the unlikely Apple/FSF merge). mentor startup crash on Darwin PPC_DARWIN? All Darwin? ie: What I reported? Yes sounds bad. Maybe the same thing as formsedit. - Jay > Date: Sat, 18 Jul 2009 14:18:22 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: admins at elego.de > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > We really need to use some tools to help us keep (or gain?) > control of the release process. Trac has been available for more > than a year, but nobody has actively used it. Maybe this is a good > time now :-) > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > See here: https://projects.elego.de/cm3/roadmap > > Please add all the problems that were just reported via mail > to the trac database with `new ticket': > https://projects.elego.de/cm3/newticket. > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > fine. Some older bug reports are also still unresolved, but we can > check them later. > > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. > > Please let's use this; I'm afraid we'll lose control without it. > > It also has the advantage that the HTTP GUI is accessible from the > customer network I'm usually working on (while everything else is > blocked). > > Thanks in advance for your cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:58:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:58:29 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: > cm3ide crash still happens -- if /cm3/examples doesn't exist. Doesn't crash if empty /cm3/examples created. To get it to crash, click on the "examples" link. Now I can't debug it, gdb won't debug my AMD64 binary, wierd. > m3tohtml crash I was able to see it crash, and then not crash with my config file changes. Since it is run in the Tinderbox though, that should provide extra confirmation. remove/simplify dynamic library version numbering? > Can be left alone. I meant specifically for this release. For next release I'd like to reconsider. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Sat, 18 Jul 2009 12:27:46 +0000 CC: admins at elego.de Subject: Re: [M3devel] RC2 Release Engineering Status and Trac-king My opinion on some of these: cm3ide crash (NIL pointer?) #1002 probably fixed but needs retesting m3tohtml crash probably fixed but needs retesting broken m3overrides probably fixed but need to wait for Tinderbox to confirm I can migrate more of them to the one master, but that's not required. And there are some variations that need to be preserved, so it has to be all human reviewed. remove/simplify dynamic library version numbering? Can be left alone. I advocate removing the versions entirely. However the "complexity" here is very hidden anyway. m3gdb doesn't build on Darwin I think we punt on this for this release. Just update the distribution building to skip it. I think the fix is probably to import Apple's fork. I don't like it either, but it's probably the "best" way (short of the unlikely Apple/FSF merge). mentor startup crash on Darwin PPC_DARWIN? All Darwin? ie: What I reported? Yes sounds bad. Maybe the same thing as formsedit. - Jay > Date: Sat, 18 Jul 2009 14:18:22 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: admins at elego.de > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > We really need to use some tools to help us keep (or gain?) > control of the release process. Trac has been available for more > than a year, but nobody has actively used it. Maybe this is a good > time now :-) > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > See here: https://projects.elego.de/cm3/roadmap > > Please add all the problems that were just reported via mail > to the trac database with `new ticket': > https://projects.elego.de/cm3/newticket. > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > fine. Some older bug reports are also still unresolved, but we can > check them later. > > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. > > Please let's use this; I'm afraid we'll lose control without it. > > It also has the advantage that the HTTP GUI is accessible from the > customer network I'm usually working on (while everything else is > blocked). > > Thanks in advance for your cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 15:07:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 13:07:22 +0000 Subject: [M3devel] I386_DARWIN lastok TInderbox red but? Message-ID: The I386_DARWIN lastok build Tinderbox shows as red, but the log looks ok. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 18 16:37:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Jul 2009 10:37:31 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: On 18 Jul 2009, at 08:58, Jay K wrote: > > cm3ide crash > > still happens -- if /cm3/examples doesn't exist. Sounds like instructions need to be explicit to install/copy the examples directory. I've not yet tried cm3ide. > Doesn't crash if empty /cm3/examples created. > To get it to crash, click on the "examples" link. > Now I can't debug it, gdb won't debug my AMD64 binary, wierd. > > > m3tohtml crash > > I was able to see it crash, and then not crash with my config file > changes. > Since it is run in the Tinderbox though, that should provide extra > confirmation. > > remove/simplify dynamic library version numbering? > > > Can be left alone. > > I meant specifically for this release. > For next release I'd like to reconsider. > > > - Jay > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 18 Jul 2009 12:27:46 +0000 > CC: admins at elego.de > Subject: Re: [M3devel] RC2 Release Engineering Status and Trac-king > > My opinion on some of these: > > cm3ide crash (NIL pointer?) #1002 > > probably fixed but needs retesting > > m3tohtml crash > > probably fixed but needs retesting > > broken m3overrides > > probably fixed but need to wait for Tinderbox to confirm > I can migrate more of them to the one master, but that's not required. > And there are some variations that need to be preserved, so it has > to be all > human reviewed. > > remove/simplify dynamic library version numbering? > > Can be left alone. > I advocate removing the versions entirely. > However the "complexity" here is very hidden anyway. > > m3gdb doesn't build on Darwin > > I think we punt on this for this release. > Just update the distribution building to skip it. > I think the fix is probably to import Apple's fork. > I don't like it either, but it's probably the "best" way (short of > the unlikely Apple/FSF merge). > > > mentor startup crash on Darwin > > PPC_DARWIN? All Darwin? > ie: What I reported? > Yes sounds bad. > Maybe the same thing as formsedit. > > > - Jay > > > > Date: Sat, 18 Jul 2009 14:18:22 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: admins at elego.de > > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > > > We really need to use some tools to help us keep (or gain?) > > control of the release process. Trac has been available for more > > than a year, but nobody has actively used it. Maybe this is a good > > time now :-) > > > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > > See here: https://projects.elego.de/cm3/roadmap > > > > Please add all the problems that were just reported via mail > > to the trac database with `new ticket': > > https://projects.elego.de/cm3/newticket. > > > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > > fine. Some older bug reports are also still unresolved, but we can > > check them later. > > > > It would also be helpful if all active developers had personalized > > access and would help updating the tickets and the WiKi. Please send > > mail to admins(at)elego.de to obtain an account from Michael or > Joffrey. > > > > Please let's use this; I'm afraid we'll lose control without it. > > > > It also has the advantage that the HTTP GUI is accessible from the > > customer network I'm usually working on (while everything else is > > blocked). > > > > Thanks in advance for your cooperation, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 18 16:36:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Jul 2009 10:36:05 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> On 18 Jul 2009, at 08:27, Jay K wrote: > mentor startup crash on Darwin > > PPC_DARWIN? All Darwin? > ie: What I reported? > Yes sounds bad. > Maybe the same thing as formsedit. > This one is serious. It is a new bug as far as I know, since I had mentor running fine about a year or so ago. > > - Jay > > > > Date: Sat, 18 Jul 2009 14:18:22 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: admins at elego.de > > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > > > We really need to use some tools to help us keep (or gain?) > > control of the release process. Trac has been available for more > > than a year, but nobody has actively used it. Maybe this is a good > > time now :-) > > > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > > See here: https://projects.elego.de/cm3/roadmap > > > > Please add all the problems that were just reported via mail > > to the trac database with `new ticket': > > https://projects.elego.de/cm3/newticket. > > > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > > fine. Some older bug reports are also still unresolved, but we can > > check them later. > > > > It would also be helpful if all active developers had personalized > > access and would help updating the tickets and the WiKi. Please send > > mail to admins(at)elego.de to obtain an account from Michael or > Joffrey. > > > > Please let's use this; I'm afraid we'll lose control without it. > > > > It also has the advantage that the HTTP GUI is accessible from the > > customer network I'm usually working on (while everything else is > > blocked). > > > > Thanks in advance for your cooperation, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 17:50:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 17:50:32 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> Message-ID: <20090718175032.cnrq4lyhcc48scog@mail.elegosoft.com> Quoting Tony Hosking : > On 18 Jul 2009, at 08:27, Jay K wrote: > >> mentor startup crash on Darwin >> >> PPC_DARWIN? All Darwin? >> ie: What I reported? >> Yes sounds bad. >> Maybe the same thing as formsedit. >> > > This one is serious. It is a new bug as far as I know, since I had > mentor running fine about a year or so ago. Thas was just my bad memory. These things happen without tracking tools. I meant formsedit (already corrected in WiKi). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 18:12:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 18:12:26 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <20090718181226.89oeqfagisggw8sw@mail.elegosoft.com> Quoting Olaf Wagner : > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. I just learned how to add new users via command line, so please just let _me_ know if you want an account. The trac installation seems to be an older version with some bugs; an update will be done during the next weeks. o self administration does not work o adding of users via Admin does not work o generated links in mails are missing /cm3/ o probably more... We'll have to live with that for the next days. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 22:01:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 22:01:44 +0200 Subject: [M3devel] current tinderbox failures Message-ID: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> I386_DARWIN failed with regression-scripts/defs.sh: line 480: ./scripts/do-cm3-core.sh: No such file or directory I don't understand that (the script is definitely there in the repo) SOLgnu fails with Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/unix/solaris-2-x/Usignal.i3 *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/unix/solaris-2-x/Usignal.i3 *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? -DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? -DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? failed *** This must be a problem in the m3makefiles in m3core. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mbishop at esoteriq.org Sat Jul 18 22:55:27 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Sat, 18 Jul 2009 15:55:27 -0500 Subject: [M3devel] It's good to be back! Message-ID: <4A6236BF.5060903@esoteriq.org> For some reason, I stopped getting m3devel messages...and when I sent an email asking if something was wrong with the list, my messages never got through...I checked the archive and saw lots of activity, but my messages never showed up...anyway, I just signed up with another email address, and am getting the messages again. Glad to see there is progress with a "real" release :) From jay.krell at cornell.edu Sun Jul 19 01:50:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 23:50:13 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: > cm3ide crash > still happens -- if /cm3/examples doesn't exist. > Sounds like instructions need to be explicit to install/copy the examples directory. I've not yet tried cm3ide. Still, it should do better when the directory isn't there. Other directories probably too. I'm not a big fan of cm3ide, or any IDE these days really, but I'll try to stick to concrete problems, which are bound to be fairly small. cm3ide is quite unusual in being browser based and that really limits it, esp. targeting browsers from long ago with just a bunch of html, using Flash or Silverlight can result in a browser-based app as good as a non-browser-based app. I don't like IDEs because..long winded, not sure anyone cares..I saved my notes in case anyone does.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 08:02:26 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 18 Jul 2009 23:02:26 -0700 Subject: [M3devel] current tinderbox failures In-Reply-To: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> References: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> Message-ID: <7855629E-9E28-4A40-A299-2FF570FFFC1B@hotmail.com> My ppc Linux run hit the same file not found error. Sparc Linux failed because I gave it a bad cm3.cfg. Still that is great progress for running tinderbox.. - Jay (phone) On Jul 18, 2009, at 1:01 PM, Olaf Wagner wrote: > I386_DARWIN failed with > > regression-scripts/defs.sh: line 480: ./scripts/do-cm3-core.sh: No > such file or directory > > I don't understand that (the script is definitely there in the repo) > > SOLgnu fails with > > Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/ > unix/solaris-2-x/Usignal.i3 > *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/ > Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/ > unix/solaris-2-x/Usignal.i3 > *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/ > niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? - > DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? $RARGS > && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/ > niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? - > DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? failed > *** > > This must be a problem in the m3makefiles in m3core. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Sun Jul 19 17:44:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 15:44:40 +0000 Subject: [M3devel] "kext" In-Reply-To: <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> Message-ID: > I didn't think of that, but I don't think it matters; there is no > program named kext on Darwin, is there? kextd kextfind kextload kextstat but no kext. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Sun Jul 19 20:49:32 2009 From: rcolebur at scires.com (Randy Coleburn) Date: 19 Jul 2009 14:49:32 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: <4A63326E.1E75.00D7.1@scires.com> >>> Olaf Wagner 7/18/2009 6:36 AM >>> >Yes, I haven't spent much thought on Windows until now. I hoped that >you or Jay will do that. Of course I've also overseen the install.cmd >scripts for Windows :-/ Should we use cmd or bat? Could somebody >quickly provide the equivalent of this loop, so that I can >automate it? > ---- >#!/bin/sh >HERE=`pwd` >for p in m3-win/import-libs ... m3-comm/tcp; do >cd $p >cm3 -ship ${SHIPARGS} >cd $HERE >done > ---- Olaf: Your script can be expressed in Windows .CMD format as follows: REM ---BEGIN--- @echo off for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p goto End :ShipIt echo ...shipping %1... pushd %1 cm3 -ship %SHIPARGS% popd echo. goto :EOF :End echo done @echo on REM ---END--- Of course, the REM lines at the beginning/end are optional, I just put them there to show start/end of the script. Also, you would want to replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of folders to be processed. You can separate them by blank spaces or semi-colons, but if you have a path with an embedded space, you will need to put double quotes around the path. FYI: If your list of paths is in a text file, there is another form of the FOR command that would work to process the list from that file. I don't mind writing .CMD files, so if you and Jay want some help in this area, I am willing to volunteer. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From rcoleburn at scires.com Sun Jul 19 20:58:38 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 14:58:38 -0400 Subject: [M3devel] release testing on Windows XP Message-ID: <4A633472.1E75.00D7.1@scires.com> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Jul 19 22:55:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 16:55:53 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A633472.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> Message-ID: <4A634FED.1E75.00D7.1@scires.com> For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:31:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:31:50 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A634FED.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:33:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:33:14 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis Message-ID: I'm finally getting some progress here! http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1248027392.25281 sparc linux looks good http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248026305.31492 x86 linux unclear but maybe ok http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248022605.3042 ppc linux merge conflict in my PPC_LINUX config file, will try again The ./scripts/do-cm3-core.sh error: Look at the bottom of: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1248038292.4235#err2 pwd 22 /home/jay/work/cm3-ws/localhost-2009-07-19-21-15-43/cm3 23 ls 24 COPYRIGHT-BSD 25 COPYRIGHT-CMASS 26 COPYRIGHT-COLUMBIA 27 COPYRIGHT-DEC 28 COPYRIGHT-JDP 29 COPYRIGHT-PURDUE 30 COPYRIGHT-XEROX 31 COPYRIGHTS 32 CVS 33 README 34 caltech-parser 35 compat.quake 36 doc 37 m3overrides 38 ls ./scripts 39 NEXT ls: cannot access ./scripts: No such file or directory 40 === build core system with current compiler 41 NEXT regression-scripts/defs.sh: line 489: ./scripts/do-cm3-core.sh: No such file or directory Notice the majority of the source is missing, not just scripts. Maybe timing out during the cvs checkout? Maybe we should put in a few cvs -z3 upds at the end of it? Maybe ensure that cvs's exit code is checked? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:33:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:33:48 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A634FED.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: [truncated yet again..] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] release testing on Windows XP Date: Sun, 19 Jul 2009 21:31:50 +0000 Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay [deliberately truncated here] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Sun Jul 19 23:43:02 2009 From: rcolebur at scires.com (Randy Coleburn) Date: 19 Jul 2009 17:43:02 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: <4A635B25.1E75.00D7.1@scires.com> do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Sun Jul 19 23:52:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:52:25 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A635B25.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> Message-ID: The "all" versions of all the scripts fail to compile (all as in Python, .sh, .cmd). Try "std". All the scripts are also a bit identically loose in how they find "projects". They look for something/src/m3makefile where something contains what they are after. It is a bit fragile. Except for your .cmd files which are more precise. There is also a bug in all the scripts that adding new packages to the source tree fails. The PKGS files needs a version number in its name and if PKGS-correctionversion doesn't exist the scripts should delete PKGS* and regenerate. We only recently got a centralized version file though and I didn't want to implement this until that was in. - Jay Date: Sun, 19 Jul 2009 17:43:02 -0400 From: rcolebur at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] release testing on Windows XP do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 00:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 22:48:24 +0000 Subject: [M3devel] Tinderbox missing do-cm3-core.sh Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039304.30290#err2 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039913.18931#err2 to more instances of missing do-cm3-core.sh. You can see in these cases the cvs checkout got much further, but still missed all of scripts. Scripts just happens to be alphabetically late so has a higher chance of not making it. Suggestions? Surely this is just as much likely flaky network on my end as anywhere else. Put a file "last" in the repository and if it is missing after checkout, abort and start over? Send the repository down as one large .tar.gz, and again, if failed to recieve, abort and start over? Could keeping a checkout and just updating it from run to run be made reliable/trusted enough? That would greatly mitigate network problems, make abort + retry less expensive. Or not much competition to the cleanliness of a whole new checkout for each build? Just run it all in an hourly loop and accept the lossage? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 00:50:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 22:50:23 +0000 Subject: [M3devel] FW: Tinderbox missing do-cm3-core.sh Message-ID: [truncated again!] From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: Tinderbox missing do-cm3-core.sh Date: Sun, 19 Jul 2009 22:48:24 +0000 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039304.30290#err2 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039913.18931#err2 to more instances of missing do-cm3-core.sh. You can see in these cases the cvs checkout got much further, but still missed all of scripts. Scripts just happens to be alphabetically late so has a higher chance of not making it. Suggestions? Surely this is just as much likely flaky network on my end as anywhere else. Put a file "last" in the repository and if it is missing after checkout, abort and start over? Send the repository down as one large .tar.gz, and again, if failed to recieve, abort and start over? Could keeping a checkout and just updating it from run to run be made reliable/trusted enough? That would greatly mitigate network problems, make abort + retry less expensive. Or not much competition to the cleanliness of a whole new checkout for each build? Just run it all in an hourly loop and accept the lossage? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Jul 20 04:19:26 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 22:19:26 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> Message-ID: <4A639BC0.1E75.00D7.1@scires.com> Ok, so here is what I've done: 1. deleted PKGS 2. scripts/win/upgrade.cmd 3. scripts/win/do-cm3-std.cmd These work, except that I had to modify pkginfo.txt as follows: 1. Removed all m3-www packages (web & proxy) 2. Removed all cvsup packages If I left these in there, I got failures. BTW, I've rebuilt cm3ide and it is running on Windows XP with no crashes so far. Now, if (?) the pkginfo.txt file is what is driving the process, it appears that each line in the file has a package and one or more tags, e.g. min std core. I assume the order of packages in pkginfo.txt is the correct build order. If these statements are true (and I'm asking you to verify), I will try to write a simpler CMD script that deals with the building process using pkginfo.txt as the "input control file". Regards, Randy Coleburn >>> Jay K 7/19/2009 5:52 PM >>> The "all" versions of all the scripts fail to compile (all as in Python, .sh, .cmd). Try "std". All the scripts are also a bit identically loose in how they find "projects". They look for something/src/m3makefile where something contains what they are after. It is a bit fragile. Except for your .cmd files which are more precise. There is also a bug in all the scripts that adding new packages to the source tree fails. The PKGS files needs a version number in its name and if PKGS-correctionversion doesn't exist the scripts should delete PKGS* and regenerate. We only recently got a centralized version file though and I didn't want to implement this until that was in. - Jay Date: Sun, 19 Jul 2009 17:43:02 -0400 From: rcolebur at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] release testing on Windows XP do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 04:52:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 19 Jul 2009 19:52:07 -0700 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A639BC0.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> Message-ID: <5115ADEF-1DA5-473A-9B15-DD2753CA25D0@hotmail.com> Correct, pkginfo.txt defines the groups and the order. Search for pkginfo. I thought it already drives the .cmd code. Pylib.py has it's own copy but easy to fix. I don't remember but I might have left provision for filtering packages. Originally I wanted the filter conditions expressed somehow in pkginfo.txt but I never did that. - Jay (phone) On Jul 19, 2009, at 7:19 PM, "Randy Coleburn" wrote: > Ok, so here is what I've done: > 1. deleted PKGS > 2. scripts/win/upgrade.cmd > 3. scripts/win/do-cm3-std.cmd > > These work, except that I had to modify pkginfo.txt as follows: > 1. Removed all m3-www packages (web & proxy) > 2. Removed all cvsup packages > > If I left these in there, I got failures. > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > crashes so far. > > Now, if (?) the pkginfo.txt file is what is driving the process, it > appears that each line in the file has a package and one or more > tags, e.g. min std core. I assume the order of packages in > pkginfo.txt is the correct build order. If these statements are > true (and I'm asking you to verify), I will try to write a simpler > CMD script that deals with the building process using pkginfo.txt as > the "input control file". > > Regards, > Randy Coleburn > > >>> Jay K 7/19/2009 5:52 PM >>> > The "all" versions of all the scripts fail to compile (all as in > Python, .sh, .cmd). > Try "std". > > All the scripts are also a bit identically loose in how they find > "projects". > They look for something/src/m3makefile where something contains > what they are after. > It is a bit fragile. > Except for your .cmd files which are more precise. > > There is also a bug in all the scripts that adding new packages to > the source tree fails. > The PKGS files needs a version number in its name and if PKGS- > correctionversion doesn't > exist the scripts should delete PKGS* and regenerate. > We only recently got a centralized version file though and I didn't > want to implement > this until that was in. > > - Jay > > > Date: Sun, 19 Jul 2009 17:43:02 -0400 > From: rcolebur at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] release testing on Windows XP > > do-cm3-all.py: This crazy python animal is now trying to compile my > examples folder! > It fails, of course, and doesn't go any farther. > Regards, > Randy Coleburn > > >>> Jay K 7/19/2009 5:31 PM >>> > Try deleting the PKGS file of course. Management of that file is > poor, across all the scripts. > Almost any version of Python will do and I highly recommend it. .cmd > is a terrible programming language and Python is an excellent one. > Python is also very portable. I use all the same automation across a > variety of platforms. > (I still haven't gotten it to work on OpenBSD/sgimips and I do > sometimes test Olaf's .sh code.) > JScript isn't so bad, and it is "built in" on essentially all > Windows installs (as long as there is IE), but it isn't portable at > all for command line use to Python wins again. I understand the > desire to not install anything at all, but this one install provides > tremendous value. Sometimes a dependency is worth it. > > - Jay > > Date: Sun, 19 Jul 2009 16:55:53 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com; rcoleburn at scires.com > Subject: Re: [M3devel] release testing on Windows XP > > For #3 below, I went to scripts/win and ran upgrade.cmd. No > problems there. > > Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www > \web package is missing. > > I suspect these scripts may not be up to date. > > Alas, I'm going to try to download python 2.6 for Windows since that > is what Jay seems to be using these days. Then I'll try running his > python scripts and see how it fares. > > But, I again think we need to not depend on python scripts for cm3 > on Windows. I am willing to work on the .CMD scripts. > > --Randy Coleburn > > >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> > Olaf / Jay / et al: > > I am back from my trip and thought I would try to test out what we > have for Windows XP platform. > > My plan is: > > 1. Backup my current cm3 tree and sandbox. > 2. Update my local sandbox copy of all CM3 from the CVS repository. > 3. Use my current cm3 to rebuild everthing in the updated sandbox. > In so doing, I will ship back to my cm3 installation thereby > updating it to be current. > 4. Use my updated cm3 to build and test a number of my programs. > 5. Report results to m3devel > > Regards, > Randy Coleburn From wagner at elegosoft.com Mon Jul 20 12:38:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 12:38:33 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: Message-ID: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Quoting Jay K : > Notice the majority of the source is missing, not just scripts. > > Maybe timing out during the cvs checkout? > Maybe we should put in a few cvs -z3 upds at the end of it? > Maybe ensure that cvs's exit code is checked? Yes, that should be checked (isn't it already?). Please add if it's missing. I think the problem may be that birch is operating under high load (at least has done all the weekend), and my attempts to do complete cm3 build didn't alleviate the situation ;-) There's something weird going on, but unfortunately our system administration people are scarce currently due to holidays... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 20 12:44:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 12:44:46 +0200 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A639BC0.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> Message-ID: <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> Quoting Randy Coleburn : > Ok, so here is what I've done: > 1. deleted PKGS > 2. scripts/win/upgrade.cmd > 3. scripts/win/do-cm3-std.cmd > > These work, except that I had to modify pkginfo.txt as follows: > 1. Removed all m3-www packages (web & proxy) > 2. Removed all cvsup packages CVSup will not build on Windows and should be excluded on that platform, but why do the www packages fail? I thought they should be OK. Is there anything specific missing for them in Windows? > If I left these in there, I got failures. > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > crashes so far. Fine. Have you tried without the example folder, too? > Now, if (?) the pkginfo.txt file is what is driving the process, it > appears that each line in the file has a package and one or more > tags, e.g. min std core. I assume the order of packages in > pkginfo.txt is the correct build order. If these statements are > true (and I'm asking you to verify), I will try to write a simpler > CMD script that deals with the building process using pkginfo.txt as > the "input control file". Yes. Sounds right. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 12:55:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 10:55:57 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: > I think the problem may be that birch is operating under high load > (at least has done all the weekend), and my attempts to do complete > cm3 build didn't alleviate the situation ;-) > > There's something weird going on, but unfortunately our system > administration people are scarce currently due to holidays... Could be me?, esp. my repeated Tinderbox runs, doing cvs checkout over and over? No more than three concurrently and not in a loop, but stil.. Three: LINUXLIBC6, PPC_LINUX, SPARC32_LINUX. I can try just one at a time. And, I added -z3 to the checkout? Good/bad/other? gzip is supposedly very non-taxing and I think -z3 is like gzip. I've heard cvs is a cpu hog, it's one reason people switch away from it (which I hope we'll do after this release..) I'll check about the cvs exit code. A few times control-c-ed cvs and my birch ssh would show some errors on syslogd about cvs. - Jay From jay.krell at cornell.edu Mon Jul 20 13:07:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 11:07:21 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: Let's put the exclusions in the three or so m3makefiles instead of coming up with sh, python, and cmd. Just like win-libs only builds on Win32. Which reminds me I should put in the X filtering that way.. And m3gdb... And anything else that isn't really up to the user because the problems run fairly deep (in extreme cases, trying to fix such things, user can edit it away). (The Interix problem with X maybe doesn't run very deep, X is mostly there, but m3gdb on Darwin, cvsup probably NT386...) After this release I think we'll go ahead and unjoin the three NT386 platforms, and rename them all... - Jay ---------------------------------------- > Date: Mon, 20 Jul 2009 12:38:33 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] tinderbox status improvements/diagnosis > > Quoting Jay K : > >> Notice the majority of the source is missing, not just scripts. >> >> Maybe timing out during the cvs checkout? >> Maybe we should put in a few cvs -z3 upds at the end of it? >> Maybe ensure that cvs's exit code is checked? > > Yes, that should be checked (isn't it already?). Please add > if it's missing. > > I think the problem may be that birch is operating under high load > (at least has done all the weekend), and my attempts to do complete > cm3 build didn't alleviate the situation ;-) > > There's something weird going on, but unfortunately our system > administration people are scarce currently due to holidays... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 20 13:12:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 11:12:38 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: wrong thread, this was about cvsup.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Mon, 20 Jul 2009 11:07:21 +0000 > Subject: Re: [M3devel] tinderbox status improvements/diagnosis > > > Let's put the exclusions in the three or so m3makefiles instead of coming up with sh, python, and cmd. Just like win-libs only builds on Win32. [snip] From wagner at elegosoft.com Mon Jul 20 13:51:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 13:51:09 +0200 Subject: [M3devel] Current CM3 test failures on AMD64_LINUX and FreeBSD Message-ID: <20090720135109.3etgatcn4w80w4gg@mail.elegosoft.com> Could anybody have a look at the test failures (red) in http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html? There are also several failures in http://www.opencm3.net/m3tests/m3tests-AMD64_LINUX-2009-07-20-06-12-30.html failures: 18 p009 needs to be adapted for 64 bit platforms (integer size). p040 number conversion routines ASCII <-> binary -- probably always a problem. Has anybody a good idea what to do here? p116b default IEEE floating point tests from Xerox PARC p126 REAL arithmetic p137 bit insert and extract -- probably a 32/64 bit issue, too? p172 REAL vs. C's float -- looks strange (wrong sign) p179 alignment of ARRAY OF BITS 32 FOR INTEGER -- package build failed p204 IP address initializers -- this looks more serious (assertion faiure) p206 ARRAY constructors in var decls using named open array types -- p.b.f. p207 subrange declarations -- p.b.f. p209 open array initializers compile failure -- assertion failure p210 open array initializers runtime failure -- NIL dereference? r002 stack overflow in the main thread -- bus error <-> segmentation fault r003 b3tests/b002 - improper size for an open array parameter -- 32/64 again? r004 negative size for an open array -- line number difference only e020 illegal recursive declaration -- p.b.f <-> segmentation fault e026 two types with the same brand -- empty??? e029 use type instead of value as an initializer -- p.b.f.: ** INTERNAL CG ERROR *** stack not empty, depth (1), looks serious For comparison, here are the failures on FreeBSD (14): p040 binary <-> ASCII conversion routines p116b default IEEE floating point tests from Xerox PARC p172 REAL vs. C's float p185 REAL vs. C float -- not on Linux p204 IP address initializers -- code generator failures p206 ARRAY constructors in var decls using named open array types p207 subrange declarations p209 open array initializers compile failure p210 open array initializers runtime failure r001 unhandled exception r004 negative size for an open array e020 illegal recursive declaration e026 two types with the same brand e029 use type instead of value as an initializer While some of these are probably only problems in the test code or method, it seems to me that we should have a closer look at all of them before the release. Explanations, adaptions of test code and cm3 fixes will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 14:38:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 12:38:31 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> Message-ID: I excluded cvsup on Win32. Everything in m3-www builds ok for me. There is a crashing struct tm bug in the tree, I vaguely recall it was in one of these barely working web browsers. They assume struct tm is the BSDish one with extra stuff at the end, which is only true on some platforms. Oh, this stuff: :\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3 :\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3 typical unsafe Modula-3... - Jay > Date: Mon, 20 Jul 2009 12:44:46 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] release testing on Windows XP > > Quoting Randy Coleburn : > > > Ok, so here is what I've done: > > 1. deleted PKGS > > 2. scripts/win/upgrade.cmd > > 3. scripts/win/do-cm3-std.cmd > > > > These work, except that I had to modify pkginfo.txt as follows: > > 1. Removed all m3-www packages (web & proxy) > > 2. Removed all cvsup packages > > CVSup will not build on Windows and should be excluded on that > platform, but why do the www packages fail? I thought they should > be OK. > > Is there anything specific missing for them in Windows? > > > If I left these in there, I got failures. > > > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > > crashes so far. > > Fine. Have you tried without the example folder, too? > > > Now, if (?) the pkginfo.txt file is what is driving the process, it > > appears that each line in the file has a package and one or more > > tags, e.g. min std core. I assume the order of packages in > > pkginfo.txt is the correct build order. If these statements are > > true (and I'm asking you to verify), I will try to write a simpler > > CMD script that deals with the building process using pkginfo.txt as > > the "input control file". > > Yes. Sounds right. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 20 14:51:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 14:51:42 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis Message-ID: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Quoting Jay K : >> I think the problem may be that birch is operating under high load >> (at least has done all the weekend), and my attempts to do complete >> cm3 build didn't alleviate the situation ;-) >> >> There's something weird going on, but unfortunately our system >> administration people are scarce currently due to holidays... > > Could be me?, esp. my repeated Tinderbox runs, doing cvs checkout > over and over? > No more than three concurrently and not in a loop, but stil.. > Three: LINUXLIBC6, PPC_LINUX, SPARC32_LINUX. > I can try just one at a time. That should be normal business; I rather meant things like the three large bzip2 processes running all day for backup purposes and eating all the cpu time... > And, I added -z3 to the checkout? Good/bad/other? > gzip is supposedly very non-taxing and I think -z3 is like gzip. I found that it's often counter productive to use compression; however, most times small levels are more pratical, so I'd suggest you try -z1. > I've heard cvs is a cpu hog, it's one reason people switch away from > it (which I hope we'll do after this release..) Not that I know... it usually sleeps while waiting for file i/o. > I'll check about the cvs exit code. > > A few times control-c-ed cvs and my birch ssh would show some errors > on syslogd about cvs. Have seen those too yesterday... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 21:04:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 19:04:41 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: How do I get tinderbox to run the tests? It looks like maybe BUILD_REL=lastok does not but letting BUILD_REL default does. I'll fake up a 5.4 install with current files... Let it be known that "lastrel" builds might actually be "lastok" builds. If you can tell which ones are mine.. > I found that it's often counter productive to use compression; > ...so I'd suggest you try -z1. I'll change it later. You might have an unusual viewpoint though -- it is fast to checkout from birch to birch. -z3 is what I recall was recommended. > > I've heard cvs is a cpu hog, it's one reason people switch away from > > it (which I hope we'll do after this release..) I'll have to search, initial searches failed. > Not that I know... it usually sleeps while waiting for file i/o. True. > > I'll check about the cvs exit code. Fix attempted. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 21:56:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 19:56:00 +0000 Subject: [M3devel] tinderbox confusing bin and root? Message-ID: On three machines now I've seen work/cm3-inst/something/bin/bin, bin/pkg, bin/man. It seems that Tinderbox might be messing up the "update"? Maybe I setup these all up wrong myself but I don't think so. I'll see if they come back. I'm just now getting Tinderbox working almost whereas before I was never able to get far. I've gotten "lastok" builds through. I haven't seen tests run but maybe the current attempts will. Since I was using e.g. a new platform SPARC32_LINUX, I setup all the "installations" just by copying files around. The instructions require a 5.4.0 release to exist. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 20 23:39:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 23:39:58 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: <20090720233958.8y2yyvyqecgo0kk0@mail.elegosoft.com> Quoting Jay K : > How do I get tinderbox to run the tests? > > It looks like maybe BUILD_REL=lastok does not but letting BUILD_REL > default does. > > I'll fake up a 5.4 install with current files... > > Let it be known that "lastrel" builds might actually be "lastok" > builds. If you can tell which ones are mine.. Just edit cm3.build like I did on birch: do_tests() { # Enable tests on birch for non-release builds. # FIXME: Must be removed when we have a new release. #if [ "${BUILD_REL}" == "rel" ] ; then std_tests 2>&1 | tee ~/tmp/cm3-tests.log #fi } Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 20 23:44:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 23:44:26 +0200 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: References: Message-ID: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Quoting Jay K : > On three machines now I've seen work/cm3-inst/something/bin/bin, > bin/pkg, bin/man. > It seems that Tinderbox might be messing up the "update"? Looks to me like a problem in shipping or in the cm3 config files... > Maybe I setup these all up wrong myself but I don't think so. > > I'll see if they come back. > > I'm just now getting Tinderbox working almost whereas before I was > never able to get far. > > I've gotten "lastok" builds through. I haven't seen tests run but > maybe the current attempts will. > > Since I was using e.g. a new platform SPARC32_LINUX, I setup all the > "installations" just by > > copying files around. The instructions require a 5.4.0 release to exist. You can just edit cm3.build as written in the last mail and then build lastok. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 01:49:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 23:49:37 +0000 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> References: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Message-ID: > Looks to me like a problem in shipping or in the cm3 config files... Thanks, you're right, I'm missing: INSTALL_ROOT = (path() & SL & "..") in the first cm3.cfg. > You can just edit cm3.build as written in the last mail and then build > lastok. ok, thanks. I don't like having to edit the file, or read the file, just want to read the documenation. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 02:42:58 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 20 Jul 2009 20:42:58 -0400 Subject: [M3devel] do-cm3.cmd for Windows Message-ID: <4A64D69D.1E75.00D7.1@scires.com> I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP that operates based on the "scripts/PkgInfo.txt" file. I have a question about the format of the "scripts/PkgInfo.txt" file. Most of the lines in this file identify a package by name as the first entry on the line. A few of them also provide a relative path to this package. If the source tree is rooted at "sandbox\cm3", we have subfolders "m3-sys", "m3-games", etc. How do we know in which unique subfolder each package is located? For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" while, "netobj" is in "sandbox\cm3\m3-comm\netobj" Then we have in PkgInfo.txt lines like: "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman\kemacs" "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" I can see the need for the relative path for "paneman/kemacs", but "m3-games/badbricks" seems to break with the established pattern. Is this an error in the current PkgInfo.txt file? Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 03:56:38 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 18:56:38 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <4A64D69D.1E75.00D7.1@scires.com> References: <4A64D69D.1E75.00D7.1@scires.com> Message-ID: <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> do-pkg.cmd already does this doesn't it? It is looking for substring matches against paths or somesuch like the .sh code. Not actually package names. - Jay (phone) On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" wrote: > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > that operates based on the "scripts/PkgInfo.txt" file. > > I have a question about the format of the "scripts/PkgInfo.txt" file. > > Most of the lines in this file identify a package by name as the > first entry on the line. A few of them also provide a relative path > to this package. > > If the source tree is rooted at "sandbox\cm3", we have subfolders > "m3-sys", "m3-games", etc. > > How do we know in which unique subfolder each package is located? > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > Then we have in PkgInfo.txt lines like: > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > \kemacs" > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > I can see the need for the relative path for "paneman/kemacs", but > "m3-games/badbricks" seems to break with the established pattern. > Is this an error in the current PkgInfo.txt file? > > Regards, > Randy Coleburn From rcoleburn at scires.com Tue Jul 21 06:50:22 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 00:50:22 -0400 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> Message-ID: <4A651097.1E75.00D7.1@scires.com> Jay: I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3-*.cmd" scripts actually do. Some of the code is pretty complex and I decided it would take me longer to figure it out than to just write a new script. Anyway, you didn't answer my questions, so I've experimented to come up with something that seems to work for the current cases in PkgInfo.txt. I've uploaded a new file "do-cm3.cmd" that processes the "PkgInfo.txt" file based on my understanding of that file's format. I've tested it locally and it seems to work for me. This one .CMD file is meant to be an alternative to all of the various "do-pkg.cmd" and "do-cm3-*.cmd" files. Here are examples of how it could be called: cd "scripts\win" do-cm3 std buildship do-cm3 game clean buildship do-cm3 game realclean build ship do-cm3 comm depends do-cm3 all buildship There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use this file, simply comment-out this block of code or set CM3_DoneSetup=TRUE at the beginning of the block to prevent it from running. If anyone tries my new script, let me know if you experience any problems and I'll try to fix them. Finally, if I want to adapt my "do-cm3.cmd" script to also handle the work of "upgrade.cmd", I'm going to need someone to explain to me the compilation and shipping order for the upgrade process. Regards, Randy Coleburn >>> 7/20/2009 9:56 PM >>> do-pkg.cmd already does this doesn't it? It is looking for substring matches against paths or somesuch like the .sh code. Not actually package names. - Jay (phone) On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" wrote: > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > that operates based on the "scripts/PkgInfo.txt" file. > > I have a question about the format of the "scripts/PkgInfo.txt" file. > > Most of the lines in this file identify a package by name as the > first entry on the line. A few of them also provide a relative path > to this package. > > If the source tree is rooted at "sandbox\cm3", we have subfolders > "m3-sys", "m3-games", etc. > > How do we know in which unique subfolder each package is located? > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > Then we have in PkgInfo.txt lines like: > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > \kemacs" > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > I can see the need for the relative path for "paneman/kemacs", but > "m3-games/badbricks" seems to break with the established pattern. > Is this an error in the current PkgInfo.txt file? > > Regards, > Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 07:28:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 07:28:14 +0200 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: References: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Message-ID: <20090721072814.5hso9gnezo84kssw@mail.elegosoft.com> Quoting Jay K : >> Looks to me like a problem in shipping or in the cm3 config files... > > Thanks, you're right, I'm missing: > > INSTALL_ROOT = (path() & SL & "..") > > in the first cm3.cfg. > >> You can just edit cm3.build as written in the last mail and then build >> lastok. > > > > ok, thanks. I don't like having to edit the file, or read the file, just want > > to read the documenation. > > Well, you have to edit the files anyway to enable the tinderbox communication. And it's no big deal to comment out three more lines ;-) Of course we could define more variables or options... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 07:08:39 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 22:08:39 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <4A651097.1E75.00D7.1@scires.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> Message-ID: <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py. - Jay (phone) On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" wrote: > Jay: > > I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- > *.cmd" scripts actually do. Some of the code is pretty complex and > I decided it would take me longer to figure it out than to just > write a new script. > > Anyway, you didn't answer my questions, so I've experimented to come > up with something that seems to work for the current cases in > PkgInfo.txt. > > I've uploaded a new file "do-cm3.cmd" that processes the > "PkgInfo.txt" file based on my understanding of that file's format. > I've tested it locally and it seems to work for me. > > This one .CMD file is meant to be an alternative to all of the > various "do-pkg.cmd" and "do-cm3-*.cmd" files. > > Here are examples of how it could be called: > cd "scripts\win" > do-cm3 std buildship > do-cm3 game clean buildship > do-cm3 game realclean build ship > do-cm3 comm depends > do-cm3 all buildship > > There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that > expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use > this file, simply comment-out this block of code or set > CM3_DoneSetup=TRUE at the beginning of the block to prevent it from > running. > > If anyone tries my new script, let me know if you experience any > problems and I'll try to fix them. > > Finally, if I want to adapt my "do-cm3.cmd" script to also handle > the work of "upgrade.cmd", I'm going to need someone to explain to > me the compilation and shipping order for the upgrade process. > > Regards, > Randy Coleburn > > >>> 7/20/2009 9:56 PM >>> > do-pkg.cmd already does this doesn't it? > It is looking for substring matches against paths or somesuch like > the .sh code. > Not actually package names. > > - Jay (phone) > > On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" > wrote: > > > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > > that operates based on the "scripts/PkgInfo.txt" file. > > > > I have a question about the format of the "scripts/PkgInfo.txt" > file. > > > > Most of the lines in this file identify a package by name as the > > first entry on the line. A few of them also provide a relative path > > to this package. > > > > If the source tree is rooted at "sandbox\cm3", we have subfolders > > "m3-sys", "m3-games", etc. > > > > How do we know in which unique subfolder each package is located? > > > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > > > Then we have in PkgInfo.txt lines like: > > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > > \kemacs" > > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > > > I can see the need for the relative path for "paneman/kemacs", but > > "m3-games/badbricks" seems to break with the established pattern. > > Is this an error in the current PkgInfo.txt file? > > > > Regards, > > Randy Coleburn > From jay.krell at cornell.edu Tue Jul 21 08:26:42 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 23:26:42 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> Message-ID: <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then clean and build in order from the bottom. You could say it starts after libm3 or at sysutils, but there is also import-libs. In future if released cm3 can build current m3core and libm3 then just build from the bottom and on up, nothing tricky. Thinking about this now I think we should have just done the trick once and then declared the resulting cm3 as the baseline, instead of this 'institutionalization' of the 'workaround' that seems to confuse everyone, and leaves compat hacks in to deal with older releases. I think we should abandon 5.4 as a base before this release so this can be cleaned up. - Jay (phone) On Jul 20, 2009, at 10:08 PM, jay.krell at cornell.edu wrote: > Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py. > > - Jay (phone) > > On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" > wrote: > >> Jay: >> >> I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- >> *.cmd" scripts actually do. Some of the code is pretty complex and >> I decided it would take me longer to figure it out than to just >> write a new script. >> >> Anyway, you didn't answer my questions, so I've experimented to >> come up with something that seems to work for the current cases in >> PkgInfo.txt. >> >> I've uploaded a new file "do-cm3.cmd" that processes the >> "PkgInfo.txt" file based on my understanding of that file's >> format. I've tested it locally and it seems to work for me. >> >> This one .CMD file is meant to be an alternative to all of the >> various "do-pkg.cmd" and "do-cm3-*.cmd" files. >> >> Here are examples of how it could be called: >> cd "scripts\win" >> do-cm3 std buildship >> do-cm3 game clean buildship >> do-cm3 game realclean build ship >> do-cm3 comm depends >> do-cm3 all buildship >> >> There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that >> expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use >> this file, simply comment-out this block of code or set >> CM3_DoneSetup=TRUE at the beginning of the block to prevent it from >> running. >> >> If anyone tries my new script, let me know if you experience any >> problems and I'll try to fix them. >> >> Finally, if I want to adapt my "do-cm3.cmd" script to also handle >> the work of "upgrade.cmd", I'm going to need someone to explain to >> me the compilation and shipping order for the upgrade process. >> >> Regards, >> Randy Coleburn >> >> >>> 7/20/2009 9:56 PM >>> >> do-pkg.cmd already does this doesn't it? >> It is looking for substring matches against paths or somesuch like >> the .sh code. >> Not actually package names. >> >> - Jay (phone) >> >> On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" >> wrote: >> >> > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/ >> XP >> > that operates based on the "scripts/PkgInfo.txt" file. >> > >> > I have a question about the format of the "scripts/PkgInfo.txt" >> file. >> > >> > Most of the lines in this file identify a package by name as the >> > first entry on the line. A few of them also provide a relative >> path >> > to this package. >> > >> > If the source tree is rooted at "sandbox\cm3", we have subfolders >> > "m3-sys", "m3-games", etc. >> > >> > How do we know in which unique subfolder each package is located? >> > >> > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" >> > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" >> > >> > Then we have in PkgInfo.txt lines like: >> > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman >> > \kemacs" >> > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" >> > >> > I can see the need for the relative path for "paneman/kemacs", but >> > "m3-games/badbricks" seems to break with the established pattern. >> > Is this an error in the current PkgInfo.txt file? >> > >> > Regards, >> > Randy Coleburn >> > From rcoleburn at scires.com Tue Jul 21 09:26:56 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 03:26:56 -0400 Subject: [M3devel] status report on Windows XP Message-ID: <4A653548.1E75.00D7.1@scires.com> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 09:38:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 03:38:53 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <4A653815.1E75.00D7.1@scires.com> I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 09:58:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 07:58:27 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: > I've even tried it with the "examples" folder missing and it still works fine. and click the examples link? - Jay Date: Tue, 21 Jul 2009 03:26:56 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] status report on Windows XP This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 10:05:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 08:05:54 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: Bear in mind some features: do-pkg (via sysinfo) does a good job of finding compiler/linker You can copy that, but I also intend to move it into the config files if I can. Though not sure e.g. path/lib/include-search is easy there. And I don't want the config files every time to launch a bunch of processes to do the probing. Maybe move the logic to cm3 itself. Maybe. sets the version defines when building cm3, by reading the version file The python, .sh, and preexisting .cmd do that. You can copy the code out though. Is a little more easily extended -- no builtin list of package groups, but not a big deal. Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. Ditto for do-cm3-std.py wrapping do-pkg.py. The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, and then improved things by introducing pkginfo.txt. Some of the generalizations aren't useful. I'm going to remove the purported support for PM3 and M3 from pylib.py for example. My Python code is still missing a nifty feature that Olaf added to the .sh where you can pass extra parameters on to cm3. Yeah we do need to filter out more packages. The package list has grown since I last used the .cmd files and pylib.py has its own list, so I might not be building those packages on any platform. I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. .cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. Again you might want to try writing JScript. It is much more natural. It can be slow but you aren't likely to notice here. And it is very portable to Windows. You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 10:24:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 08:24:44 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: > Yeah we do need to filter out more packages. If you look for "FilterOnePackage" in pkginfo.cmd you can see this support. I'll see about moving it to the m3makefiles instead though. I'm not sure it deals with the slashes in some of the package paths either. Well..err..clearly not, but not hard to fix. Anyway, I'll see about the m3makefiles. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Tue, 21 Jul 2009 08:05:54 +0000 Subject: Re: [M3devel] status report on Windows XP Bear in mind some features: do-pkg (via sysinfo) does a good job of finding compiler/linker You can copy that, but I also intend to move it into the config files if I can. Though not sure e.g. path/lib/include-search is easy there. And I don't want the config files every time to launch a bunch of processes to do the probing. Maybe move the logic to cm3 itself. Maybe. sets the version defines when building cm3, by reading the version file The python, .sh, and preexisting .cmd do that. You can copy the code out though. Is a little more easily extended -- no builtin list of package groups, but not a big deal. Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. Ditto for do-cm3-std.py wrapping do-pkg.py. The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, and then improved things by introducing pkginfo.txt. Some of the generalizations aren't useful. I'm going to remove the purported support for PM3 and M3 from pylib.py for example. My Python code is still missing a nifty feature that Olaf added to the .sh where you can pass extra parameters on to cm3. Yeah we do need to filter out more packages. The package list has grown since I last used the .cmd files and pylib.py has its own list, so I might not be building those packages on any platform. I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. .cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. Again you might want to try writing JScript. It is much more natural. It can be slow but you aren't likely to notice here. And it is very portable to Windows. You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 10:45:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 10:45:25 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> Message-ID: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > clean and build in order from the bottom. You could say it starts after > libm3 or at sysutils, but there is also import-libs. In future if > released cm3 can build current m3core and libm3 then just build from > the bottom and on up, nothing tricky. Thinking about this now I think > we should have just done the trick once and then declared the resulting > cm3 as the baseline, instead of this 'institutionalization' of the > 'workaround' that seems to confuse everyone, and leaves compat hacks in > to deal with older releases. I think we should abandon 5.4 as a base > before this release so this can be cleaned up. Jay, there is a subtle dependency between the platforms that are contained in cm3 and m3core. You cannot compile a newer m3core with a compiler that doesn't support new platforms. At least I am not aware that this dependency has been removed, or has it? Please explain again in case I missed something. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 10:52:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 10:52:45 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> Quoting Randy Coleburn : > This report is for Windows XP Professional, Service Pack 3, using > Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft > .NET Framework Version 3.5 SP1. > > I've updated my local sandbox to be current with the CM3 CVS > repository at elego. I've performed a "upgrade.cmd" to upgrade my > cm3 compiler to the latest version. > > I kept running into problems with "scripts\win\do-cm3-std.CMD" > stopping short with an error message. > > So, I built my own "do-cm3.CMD" and used it to rebuild everything. > > Here are the packages that fail to build (I think most of these are > not supported currently on Windows): > m3-sys\m3cc > m3-libs\tcl > caltech-parser\term > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib\test We should exclude these packages from builds on Windows for the time being. I'm not sure why the caltech-parser is Unix-dependent, but we can fix that later. > m3-tools\pp Pretty printing shouldn't be Unix-dependent, too, at least I'd think so, but it's also no problem for the release. Nonetheless, coould you write two tickets in trac about failing compilation for the caltech-parser and pp on NT386? Just to make sure we won't forget about it... > I've also built tested CM3IDE and it seems to work fine on Windows. > I've even tried it with the "examples" folder missing and it still > works fine. So it's not reproducible? Or has anything been changed? > I'll try to check out how well some of the other packages run as > time permits. Fine. Thanks for the tests and the report, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 11:02:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 09:02:00 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: I fixed that bug at least in libm3. The dependency was easily removed and very painful when present. see: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 Is there more of it? I haven't see the error in a while. Coincidence? I can test it out.. - Jay > Date: Tue, 21 Jul 2009 10:45:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting jay.krell at cornell.edu: > > > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > > clean and build in order from the bottom. You could say it starts after > > libm3 or at sysutils, but there is also import-libs. In future if > > released cm3 can build current m3core and libm3 then just build from > > the bottom and on up, nothing tricky. Thinking about this now I think > > we should have just done the trick once and then declared the resulting > > cm3 as the baseline, instead of this 'institutionalization' of the > > 'workaround' that seems to confuse everyone, and leaves compat hacks in > > to deal with older releases. I think we should abandon 5.4 as a base > > before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 11:09:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 09:09:11 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: also: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/OSConfigPosix.m3.diff?r1=1.21;r2=1.22 a bunch of dead strings also removed.. There are references to the Compiler type in m3core. C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTDebug.m3(9): EOL = ARRAY Compiler.OS OF TEXT { "\n", "\r\n" }[ Compiler.ThisOS ]; C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RuntimeError.m3(16): self := LOOPHOLE (Compiler.ThisException(), RT0.ActivationPtr).exception; I don't think these are problems, but agreed it is a little fragile. The problem is presumably only present if Compiler.Platform or Compiler.ThisPlatform is referenced. The first use breaks of OS = {Win32, Posix} grows, but that is also trivially fixed. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Tue, 21 Jul 2009 09:02:00 +0000 Subject: Re: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows I fixed that bug at least in libm3. The dependency was easily removed and very painful when present. see: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 Is there more of it? I haven't see the error in a while. Coincidence? I can test it out.. - Jay > Date: Tue, 21 Jul 2009 10:45:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting jay.krell at cornell.edu: > > > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > > clean and build in order from the bottom. You could say it starts after > > libm3 or at sysutils, but there is also import-libs. In future if > > released cm3 can build current m3core and libm3 then just build from > > the bottom and on up, nothing tricky. Thinking about this now I think > > we should have just done the trick once and then declared the resulting > > cm3 as the baseline, instead of this 'institutionalization' of the > > 'workaround' that seems to confuse everyone, and leaves compat hacks in > > to deal with older releases. I think we should abandon 5.4 as a base > > before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 13:30:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 13:30:18 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Quoting Jay K : > I fixed that bug at least in libm3. The dependency was easily > removed and very painful when present. > > see: > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 And that was all? > Is there more of it? I don't know offhand. > I haven't see the error in a while. Coincidence? > > I can test it out.. Yes, please retest it, and if compilation works after addition of a new platform without complex boot upgrade, we'll forget about it. It would be great if that's really past! Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 13:43:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:43:18 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Message-ID: There was another file, C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\OSConfigPosix.m3 or such. and this hack was altered: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(505): IF SocketPosix_IsUltrixOrOSF.Value THEN it was already a hack, and it is still a hack, just not with the bad dependency any longer. Yes, I believe it is fixed. I can't reproduce the problem. I added a target to just C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\Compiler.tmpl which I believe is the only relevant thing in m3core and libm3. The other stuff in libm3 used to be relevant. Hey, /if/ I'm wrong, /and/ we can't fix it, we can go back to the old way. I do have more targets for after 5.8 hopefully. Fixing of the names might be via just adding new targets for example: I386_NT, I386_CYGWIN, I386_MINGW or I386_MINGNUWIN, I386_LINUX, I386_FREEBSD, I386_NETBSD, just not sure about SPARC_SOLARIS or SPARC32_SOLARIS and how to differentiate SOLgnu vs. SOLsun... and other "real" targets anyway, ALPHA_LINUX, ALPHA_*BSD.... Anecdotally I can tell you that even when I knew about and understood the problem, I still encountered the error a bunch, and would fix it. I don't recall seeing it in a while. - Jay > Date: Tue, 21 Jul 2009 13:30:18 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting Jay K : > > > I fixed that bug at least in libm3. The dependency was easily > > removed and very painful when present. > > > > see: > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 > > And that was all? > > > Is there more of it? > > I don't know offhand. > > > I haven't see the error in a while. Coincidence? > > > > I can test it out.. > > Yes, please retest it, and if compilation works after addition of > a new platform without complex boot upgrade, we'll forget about it. > > It would be great if that's really past! > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 13:49:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:49:21 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: These should all be ok now except for m3cc. Hopefully you can filter it out somehow. After the 5.8 release I'll split up the NT386 platforms into three platforms and then the m3cc/src/m3makefile can do the filtering naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but disallowing it for I386_NT). tcl has other problems imho, I disabled it for Win32. It is a massive clone of C headers from years ago and could easily be out of date. The right fix anyway is probably to add Tcl to SYSLIBS -- venturing on actually needing the config files to actually vary per user.. pp requires lex/yacc or flex/bison, and would give an error indicating so. Now it just does nothing if they are missing. caltech requires termios/cfmakeraw, I put in a do-nothing version of Win32 and fixed the Posix version to be safer, more portable, and more and less efficient. I don't know why it was disabling the garbage collector so I removed that. Was that termios.i3 actually portable? Are the structs of known size across all Posix systems and the constants constant? A better Win32 implementation probably isn't difficult. It'd be great if anyone could sign up and say they use this caltech parser stuff, including the terminal stuff it is doing (try removing the cfmakeraw call, notice a difference, and test the Win32 version and verify it doesn't work great..?) Actually I ran some of the executables there and got some usage statements and an array index out of bounds or such in some gui code.. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 13:50:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:50:27 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: [truncated..no big deal...] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] status report on Windows XP Date: Tue, 21 Jul 2009 11:49:21 +0000 These should all be ok now except for m3cc. Hopefully you can filter it out somehow. After the 5.8 release I'll split up the NT386 platforms into three platforms and then the m3cc/src/m3makefile can do the filtering naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but disallowing it for I386_NT). tcl has other problems imho, I disabled it for Win32. It is a massive clone of C headers from years ago and could easily be out of date. The right fix anyway is probably to add Tcl to SYSLIBS -- venturing on actually needing the config files to actually vary per user.. pp requires lex/yacc or flex/bison, and would give an error indicating so. Now it just does nothing if they are missing. caltech requires termios/cfmakeraw, I put in a do-nothing version of Win32 and fixed the Posix version to be safer, more portable, and more and less efficient. I don't know why it was disabling the garbage collector so I removed that. Was that termios.i3 actually portable? Are the structs of known size across all Posix systems and the constants constant? A better Win32 implementation probably isn't difficult. It'd be great if anyone could sign up and say they use this caltech parser stuff, including the terminal stuff it is doing (try removing the cfmakeraw call, notice a difference, and test the Win32 version and verify it doesn't work great..?) Actually I ran some of the executables there and got some usage statements and an array index out of bounds or such in some gui code.. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 14:25:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 12:25:38 +0000 Subject: [M3devel] libodbc may conflict with libodbc.... Message-ID: http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html#tr_m3-sys-cm3 I see that our libodbc.a may conflict with the "real" one. We should probably rename to libm3odbc or such. - Jay From jay.krell at cornell.edu Tue Jul 21 14:37:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 12:37:15 +0000 Subject: [M3devel] config file issue Message-ID: Olaf..sorry, this movement to the config directory seemed very easy at the time..and it is still not quite working. http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/cm3cfg.common", line 170: quake runtime error: undefined variable: ROOT That's probably an old version, where the use isn't guarded with if defined. upgrade.sh: if [ ! -d "${INSTALLROOT}/bin/config" ]; then echo "create new config sub directory ${INSTALLROOT}/bin/config" cp_config_files fi Why the guard with ! -d? How about just always do it? There are other paths...I don't understand..how about just always do it? - Jay From wagner at elegosoft.com Tue Jul 21 16:41:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 16:41:01 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Message-ID: <20090721164101.jjmx0bbk04cc840g@mail.elegosoft.com> Great! Thanks, Olaf Quoting Jay K : > There was another file, > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\OSConfigPosix.m3 or such. > and this hack was altered: > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(505): IF > SocketPosix_IsUltrixOrOSF.Value THEN > > > it was already a hack, and it is still a hack, just not with the bad > dependency any longer. > > > > Yes, I believe it is fixed. > > I can't reproduce the problem. > > I added a target to just > C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\Compiler.tmpl > > which I believe is the only relevant thing in m3core and libm3. > > The other stuff in libm3 used to be relevant. > > > > Hey, /if/ I'm wrong, /and/ we can't fix it, we can go back to the old way. > > I do have more targets for after 5.8 hopefully. > > Fixing of the names might be via just adding new targets for > example: I386_NT, I386_CYGWIN, I386_MINGW or I386_MINGNUWIN, > I386_LINUX, I386_FREEBSD, I386_NETBSD, just not sure about > SPARC_SOLARIS or SPARC32_SOLARIS and how to differentiate SOLgnu vs. > SOLsun... and other "real" targets anyway, ALPHA_LINUX, > ALPHA_*BSD.... > > > > > > Anecdotally I can tell you that even when I knew about and > understood the problem, I still encountered the error a bunch, and > would fix it. I don't recall seeing it in a while. > > > > > > - Jay > >> Date: Tue, 21 Jul 2009 13:30:18 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows >> >> Quoting Jay K : >> >> > I fixed that bug at least in libm3. The dependency was easily >> > removed and very painful when present. >> > >> > see: >> > >> > >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 >> > >> > >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 >> >> And that was all? >> >> > Is there more of it? >> >> I don't know offhand. >> >> > I haven't see the error in a while. Coincidence? >> > >> > I can test it out.. >> >> Yes, please retest it, and if compilation works after addition of >> a new platform without complex boot upgrade, we'll forget about it. >> >> It would be great if that's really past! >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Tue Jul 21 16:42:04 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 10:42:04 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <4A659B7C.1E75.00D7.1@scires.com> yes, I can click the link and cm3ide reports that the examples are not available. --Randy >>> Jay K 7/21/2009 3:58 AM >>> > I've even tried it with the "examples" folder missing and it still works fine. and click the examples link? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Tue Jul 21 16:43:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 16:43:37 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: <20090721164337.j7bbvffiuc08c44k@mail.elegosoft.com> Quoting Jay K : > These should all be ok now except for m3cc. > > Hopefully you can filter it out somehow. > > After the 5.8 release I'll split up the NT386 platforms into three > platforms and then the m3cc/src/m3makefile can do the filtering > naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but > disallowing it for I386_NT). > > tcl has other problems imho, I disabled it for Win32. > > It is a massive clone of C headers from years ago and could easily > be out of date. > > The right fix anyway is probably to add Tcl to SYSLIBS -- venturing > on actually needing the config files to actually vary per user.. Is really anybody using TCL these days? Probably the right thing to do is just remove it ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Jul 21 17:02:28 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:02:28 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: <4A65A009.1E75.00D7.1@scires.com> >>> Jay K 7/21/2009 4:05 AM >>> >Bear in mind some features:> > do-pkg (via sysinfo) does a good job of finding compiler/linker > You can copy that, but I also intend to move it into the config files if I can. > Though not sure e.g. path/lib/include-search is easy there. > And I don't want the config files every time to launch a bunch of processes to do the probing. > Maybe move the logic to cm3 itself. Maybe. My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > sets the version defines when building cm3, by reading the version file > The python, .sh, and preexisting .cmd do that. You can copy the code out though. I thought the version information was built into the compiler? >Is a little more easily extended -- no builtin list of package groups, but not a big deal. >Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >Ditto for do-cm3-std.py wrapping do-pkg.py. This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. >The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >and then improved things by introducing pkginfo.txt. My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. >Some of the generalizations aren't useful. >I'm going to remove the purported support for PM3 and M3 from pylib.py for example. >My Python code is still missing a nifty feature that Olaf added to the .sh where you can >pass extra parameters on to cm3. My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. >Yeah we do need to filter out more packages. >The package list has grown since I last used the .cmd files and pylib.py has its own list, >so I might not be building those packages on any platform. >I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. >.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >Again you might want to try writing JScript. It is much more natural. It can be slow >but you aren't likely to notice here. And it is very portable to Windows. >You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 17:10:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:10:41 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> References: <4A653548.1E75.00D7.1@scires.com> <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> Message-ID: <4A65A1F7.1E75.00D7.1@scires.com> >>> Olaf Wagner 7/21/2009 4:52 AM >>> >Nonetheless, coould you write two tickets in trac about failing >compilation for the caltech-parser and pp on NT386? >Just to make sure we won't forget about it... I can do this, but I will need an account on trac I think in order to do it. Can you set this up for me? --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 17:17:24 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:17:24 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090721095537.18D8ECC806@birch.elegosoft.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> Message-ID: <4A65A389.1E75.00D7.1@scires.com> Granted, I see that Term.m3 is an UNSAFE module, so that by definition means it is not portable. Why though do we want to replace it by nasty C code where non-portable stuff can be easily hidden? This is Modula-3. Why not fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 cents.) --Randy >>> Jay Krell 7/21/2009 11:55 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/07/21 11:55:36 Added files: cm3/caltech-parser/term/src/: TermC.c Log message: initial copy of dangerous non portable Term.m3 to rewrite portably and have it do nothing silently on Win32 which should suffice, or if not, can probably be done better, specifically the MakeRaw function CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 17:18:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:18:49 +0200 Subject: [M3devel] libodbc may conflict with libodbc.... In-Reply-To: References: Message-ID: <20090721171849.52nhb28p8kocwswo@mail.elegosoft.com> Quoting Jay K : > http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html#tr_m3-sys-cm3 > > I see that our libodbc.a may conflict with the "real" one. > We should probably rename to libm3odbc or such. Yes, pelase do. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 17:26:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:26:14 +0200 Subject: [M3devel] config file issue In-Reply-To: References: Message-ID: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> Quoting Jay K : > Olaf..sorry, this movement to the config directory seemed very easy > at the time..and it is still not quite working. > > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 > > > "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/cm3cfg.common", line > 170: quake runtime error: undefined variable: ROOT > > > That's probably an old version, where the use isn't guarded with if defined. > > upgrade.sh: > > if [ ! -d "${INSTALLROOT}/bin/config" ]; then > echo "create new config sub directory ${INSTALLROOT}/bin/config" > cp_config_files > fi > > > Why the guard with ! -d? > How about just always do it? > > There are other paths...I don't understand..how about just always do it? The original idea was to update config files only if the upgrade failed otherwise. That was to preserve any adaptions the end user might have made. To do it right in a real upgrade would require an interactive merge. I've got no problem with forcing the upgrade every time but keeping a backup. Of course, the user will immediately overwrite that with just repeating the command, if we don't version the backup... Please also consider that most users will have the single cm3.cfg which contains everything, while yours just delegates... So I'd vote for providing a backup with a timestamp and then forcing everything to use the new files. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 17:42:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:42:16 +0200 Subject: [M3devel] CM3 Trac access, was: Re: status report on Windows XP Message-ID: <20090721174216.e9wm4hax5sgkkcog@mail.elegosoft.com> Quoting Randy Coleburn : >>>> Olaf Wagner 7/21/2009 4:52 AM >>> >> Nonetheless, coould you write two tickets in trac about failing >> compilation for the caltech-parser and pp on NT386? >> Just to make sure we won't forget about it... > I can do this, but I will need an account on trac I think in order > to do it. Can you set this up for me? Any user should be able to create a new ticket in trac; at least that's how it should be. The link has been on our web pages for over a year; actually nobody has written a ticket, as far as I know ;-) But there were no complaints, too. There are only some old reports migrated grom GNATS. Let me know if it works without password; I'll setup an account for you nonetheless, but can do that only later from home, as the GUI admin function is broken. If anybody would like access, let me know now so I can do it in a batch... Olaf From hosking at cs.purdue.edu Tue Jul 21 18:03:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 12:03:35 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A65A389.1E75.00D7.1@scires.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> Message-ID: <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Hear, hear! Sent from my iPhone On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" wrote: > Granted, I see that Term.m3 is an UNSAFE module, so that by > definition means it is not portable. > Why though do we want to replace it by nasty C code where non- > portable stuff can be easily hidden? This is Modula-3. Why not fix > the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 cents.) > --Randy > > >>> Jay Krell 7/21/2009 11:55 AM >>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/07/21 11:55:36 > > Added files: > cm3/caltech-parser/term/src/: TermC.c > > Log message: > initial copy of dangerous non portable Term.m3 to rewrite portably > and have it do nothing silently on Win32 which should suffice, or if > not, can probably be done better, specifically the MakeRaw function > > From wagner at elegosoft.com Tue Jul 21 18:10:02 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 18:10:02 +0200 Subject: [M3devel] CM3 Continuous Integration with Hudson Message-ID: <20090721181002.7gak37gaaogwg8k8@mail.elegosoft.com> While in preparation for the pending release the target platforms in our tinderbox have grown significantly (though many are still red), I've set up some initial build and test jobs on a new system, which I'd like to replace Tinderbox gradually with during the next weeks or months. Have a look at http://hudson.modula3.com:8080/view/cm3/ Hudson is much more flexible and easier to use than Tinderbox. It can be completely configured and administered via HTTP, including upgrade and restart, which is a big plus at least for me currently (closed network except for HTTP). We can reuse most of the existing scripts, just need to change and adapt some settings. And convert our test results to JUnit XML format, but that's easy, too. Here are some of the advantages I see: o easy setup and configuration o easy online administration o very flexible setup of arbitrary jobs o default integration of CVS and Subversion version control systems, plug-ins for many more o easy integration of HTML and other documents see http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-FreeBSD4/ for an example o continuous integration via CVS polling working out of the box see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/changes and http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/scmPollLog/ o version control integration working out of the box: see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/37/changes#detail2 and http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile?r1=1.51&r2=1.52 o integrated history and trend reports: see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/buildTimeTrend (needs JUnit format for test result evaluation, not done yet) o HTTP access to the complete workspace see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/ws/cm3/ o job report feeds for browser integration see http://hudson.modula3.com:8080/view/cm3/rssFailed o easy configuration backup, migration and transfer, as everything is stored in plain XML files And here are some disadvantages: o more heavyweight, needs more cpu and memory o needs slave installation on every build platform o needs ssh access for slave control, but allows publishing of job results from independent servers (not tested yet) o is written in Java and not Modula-3 :-) I've setup birch as master which also runs jobs for the AMD64_LINUX target platform, and my home computer as a slave server for FreeBSD. If anybody wants access to view the configuration details or try something him/herself, just let me know and I'll set up an account. I also plan to setup actual installation tests before the release. Have fun, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Jul 21 18:19:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 12:19:12 -0400 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: I think Jay already removed the dependency. Yes? Sent from my iPhone On Jul 21, 2009, at 4:45 AM, Olaf Wagner wrote: > Quoting jay.krell at cornell.edu: > >> Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then >> clean and build in order from the bottom. You could say it starts >> after >> libm3 or at sysutils, but there is also import-libs. In future if >> released cm3 can build current m3core and libm3 then just build from >> the bottom and on up, nothing tricky. Thinking about this now I think >> we should have just done the trick once and then declared the >> resulting >> cm3 as the baseline, instead of this 'institutionalization' of the >> 'workaround' that seems to confuse everyone, and leaves compat >> hacks in >> to deal with older releases. I think we should abandon 5.4 as a base >> before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Jul 21 19:53:10 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 21 Jul 2009 10:53:10 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: I might have left it able to be called safe. Honestly I look more for human verifiable safety and correctness and it lacked those before and now does not. If that coincides with machine verifable safety, great. Either way you need C here for correctness and safety. It isn't 'nasty'. Not using C here would be nasty. I think you have it backwards. UNLESS the sizes and constants here are well known but reading docs quickly I didn't see that. Unsafe does not imply not portable. - Jay (phone) On Jul 21, 2009, at 9:03 AM, Tony Hosking wrote: > Hear, hear! > > > Sent from my iPhone > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > wrote: > >> Granted, I see that Term.m3 is an UNSAFE module, so that by >> definition means it is not portable. >> Why though do we want to replace it by nasty C code where non- >> portable stuff can be easily hidden? This is Modula-3. Why not >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >> cents.) >> --Randy >> >> >>> Jay Krell 7/21/2009 11:55 AM >>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/07/21 11:55:36 >> >> Added files: >> cm3/caltech-parser/term/src/: TermC.c >> >> Log message: >> initial copy of dangerous non portable Term.m3 to rewrite portably >> and have it do nothing silently on Win32 which should suffice, or >> if not, can probably be done better, specifically the MakeRaw >> function >> >> > From hosking at cs.purdue.edu Tue Jul 21 20:25:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 14:25:44 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> I assume the argument here is the same as for the POSIX interfaces. Sent from my iPhone On Jul 21, 2009, at 1:53 PM, jay.krell at cornell.edu wrote: > I might have left it able to be called safe. Honestly I look more > for human verifiable safety and correctness and it lacked those > before and now does not. If that coincides with machine verifable > safety, great. Either way you need C here for correctness and > safety. It isn't 'nasty'. Not using C here would be nasty. I think > you have it backwards. UNLESS the sizes and constants here are well > known but reading docs quickly I didn't see that. Unsafe does not > imply not portable. > > - Jay (phone) > > On Jul 21, 2009, at 9:03 AM, Tony Hosking > wrote: > >> Hear, hear! >> >> >> Sent from my iPhone >> >> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >> wrote: >> >>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>> definition means it is not portable. >>> Why though do we want to replace it by nasty C code where non- >>> portable stuff can be easily hidden? This is Modula-3. Why not >>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>> cents.) >>> --Randy >>> >>> >>> Jay Krell 7/21/2009 11:55 AM >>> >>> CVSROOT:/usr/cvs >>> Changes by:jkrell at birch.09/07/21 11:55:36 >>> >>> Added files: >>> cm3/caltech-parser/term/src/: TermC.c >>> >>> Log message: >>> initial copy of dangerous non portable Term.m3 to rewrite portably >>> and have it do nothing silently on Win32 which should suffice, or >>> if not, can probably be done better, specifically the MakeRaw >>> function >>> >>> >> From jay.krell at cornell.edu Tue Jul 21 20:24:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 21 Jul 2009 11:24:05 -0700 Subject: [M3devel] config file issue In-Reply-To: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> References: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> Message-ID: <94281F12-A8E5-4380-BE59-9C7145546679@hotmail.com> Agreed backup and always update. I don't want to consider merging. These are more code than data, but a mix. (code is data...the CPU is an interpreter...) I would like to aim for not needing user edits but that may be impossible to achieve. - Jay (phone) On Jul 21, 2009, at 8:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> Olaf..sorry, this movement to the config directory seemed very >> easy at the time..and it is still not quite working. >> >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 >> >> >> "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/ >> cm3cfg.common", line 170: quake runtime error: undefined variable: >> ROOT >> >> >> That's probably an old version, where the use isn't guarded with if >> defined. >> >> upgrade.sh: >> >> if [ ! -d "${INSTALLROOT}/bin/config" ]; then >> echo "create new config sub directory ${INSTALLROOT}/bin/config" >> cp_config_files >> fi >> >> >> Why the guard with ! -d? >> How about just always do it? >> >> There are other paths...I don't understand..how about just always >> do it? > > The original idea was to update config files only if the upgrade > failed otherwise. That was to preserve any adaptions the end user > might have made. > > To do it right in a real upgrade would require an interactive merge. > I've got no problem with forcing the upgrade every time but keeping > a backup. Of course, the user will immediately overwrite that with > just repeating the command, if we don't version the backup... > > Please also consider that most users will have the single cm3.cfg > which contains everything, while yours just delegates... > > So I'd vote for providing a backup with a timestamp and then forcing > everything to use the new files. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From wagner at elegosoft.com Tue Jul 21 23:19:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 23:19:54 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: <20090721231954.c54oomrbwwcc48cc@mail.elegosoft.com> Quoting Tony Hosking : > I think Jay already removed the dependency. Yes? Seems he did, though I must have missed it :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Jul 21 23:53:31 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 17:53:31 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: <4A66005F.1E75.00D7.1@scires.com> Jay: I guess this topic is just a pet peeve of mine. We tout Modula-3 as a systems programming language and that it has all these great features that make it superior to languages that lack them, yet when we "don't practice what we preach" and use another language it weakens the argument. IMO, using C instead of Modula-3 is kind of like saying that we love baseball, but we have to use soccer to play baseball the right way. It just doesn't add up. I think we should always use Modula-3 in developing and enhancing the CM3 system. I must also disagree with you and state that for a TRUE Modula-3 fan, C is indeed "nasty." All that said, I haven't looked at the code in question here. I simply commented on the idea of replacing M3 code with C code. Regards, Randy >>> 7/21/2009 1:53 PM >>> I might have left it able to be called safe. Honestly I look more for human verifiable safety and correctness and it lacked those before and now does not. If that coincides with machine verifable safety, great. Either way you need C here for correctness and safety. It isn't 'nasty'. Not using C here would be nasty. I think you have it backwards. UNLESS the sizes and constants here are well known but reading docs quickly I didn't see that. Unsafe does not imply not portable. - Jay (phone) On Jul 21, 2009, at 9:03 AM, Tony Hosking wrote: > Hear, hear! > > > Sent from my iPhone > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > wrote: > >> Granted, I see that Term.m3 is an UNSAFE module, so that by >> definition means it is not portable. >> Why though do we want to replace it by nasty C code where non- >> portable stuff can be easily hidden? This is Modula-3. Why not >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >> cents.) >> --Randy >> >> >>> Jay Krell 7/21/2009 11:55 AM >>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/07/21 11:55:36 >> >> Added files: >> cm3/caltech-parser/term/src/: TermC.c >> >> Log message: >> initial copy of dangerous non portable Term.m3 to rewrite portably >> and have it do nothing silently on Win32 which should suffice, or >> if not, can probably be done better, specifically the MakeRaw >> function >> >> > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 23:59:47 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 17:59:47 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> Message-ID: <4A6601D6.1E75.00D7.1@scires.com> Jay, Glad to hear the PkgInfo.txt is viable and being maintained. Right now, I just don't have the time and motivation to learn jscript. I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine. The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks. Regards, Randy >>> 7/21/2009 2:11 PM >>> Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform. The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it. You do have jscript installed and it is pretty easy to read and learn. pkginfo.txt is important and maintained, yes. I need to switch the python to it. Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is. Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate. - Jay (phone) On Jul 21, 2009, at 8:02 AM, "Randy Coleburn" wrote: >>> Jay K 7/21/2009 4:05 AM >>> >Bear in mind some features:> > do-pkg (via sysinfo) does a good job of finding compiler/linker > You can copy that, but I also intend to move it into the config files if I can. > Though not sure e.g. path/lib/include-search is easy there. > And I don't want the config files every time to launch a bunch of processes to do the probing. > Maybe move the logic to cm3 itself. Maybe. My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > sets the version defines when building cm3, by reading the version file > The python, .sh, and preexisting .cmd do that. You can copy the code out though. I thought the version information was built into the compiler? >Is a little more easily extended -- no builtin list of package groups, but not a big deal. >Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >Ditto for do-cm3-std.py wrapping do-pkg.py. This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. >The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >and then improved things by introducing pkginfo.txt. My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. >Some of the generalizations aren't useful. >I'm going to remove the purported support for PM3 and M3 from pylib.py for example. >My Python code is still missing a nifty feature that Olaf added to the .sh where you can >pass extra parameters on to cm3. My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. >Yeah we do need to filter out more packages. >The package list has grown since I last used the .cmd files and pylib.py has its own list, >so I might not be building those packages on any platform. >I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. >.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >Again you might want to try writing JScript. It is much more natural. It can be slow >but you aren't likely to notice here. And it is very portable to Windows. >You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 22 00:37:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 22:37:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> Message-ID: Correct. Unless this stuff is "well known" -- like the chmod values -- the code was wrong and/or highly platform specific, yet blithely did the same thing for all platforms. struct termio ws declared as merely an array of 500 char. Just an arbitrary size hoped to be large enough? Or known to be surely large enough? Or even exactly the right size? There was also a race condition in the initialization, typical, though arguably there still is. "Look at the code, not just checkin comments or the file extensions" I like to think to advise people. Except for .sh and .cmd, that I can indict just by extension. :) As I understand, when writing C code to interface to Modula-3, one has to really think about it before marking the interface as safe. For example, the C code I provided trusts the pointers it is given. So it is probably not safe. I would probably need to check the struct termios I get and compare them to the two known ones and only dereference them if it is one of them. NULL could also be deemed ok, as long as I silently did nothing with it, no dereference. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Tue, 21 Jul 2009 14:25:44 -0400 > CC: rcoleburn at scires.com; m3devel at elegosoft.com > > I assume the argument here is the same as for the POSIX interfaces. > > Sent from my iPhone > > On Jul 21, 2009, at 1:53 PM, jay.krell at cornell.edu wrote: > >> I might have left it able to be called safe. Honestly I look more >> for human verifiable safety and correctness and it lacked those >> before and now does not. If that coincides with machine verifable >> safety, great. Either way you need C here for correctness and >> safety. It isn't 'nasty'. Not using C here would be nasty. I think >> you have it backwards. UNLESS the sizes and constants here are well >> known but reading docs quickly I didn't see that. Unsafe does not >> imply not portable. >> >> - Jay (phone) >> >> On Jul 21, 2009, at 9:03 AM, Tony Hosking >> wrote: >> >>> Hear, hear! >>> >>> >>> Sent from my iPhone >>> >>> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >>> wrote: >>> >>>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>>> definition means it is not portable. >>>> Why though do we want to replace it by nasty C code where non- >>>> portable stuff can be easily hidden? This is Modula-3. Why not >>>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>>> cents.) >>>> --Randy >>>> >>>>>>> Jay Krell 7/21/2009 11:55 AM>>> >>>> CVSROOT:/usr/cvs >>>> Changes by:jkrell at birch.09/07/21 11:55:36 >>>> >>>> Added files: >>>> cm3/caltech-parser/term/src/: TermC.c >>>> >>>> Log message: >>>> initial copy of dangerous non portable Term.m3 to rewrite portably >>>> and have it do nothing silently on Win32 which should suffice, or >>>> if not, can probably be done better, specifically the MakeRaw >>>> function >>>> >>>> >>> From jay.krell at cornell.edu Wed Jul 22 00:39:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 22:39:34 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A6601D6.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> Message-ID: I use the Python all the time on various platforms. It works. The .cmds I wrote I rarely use, and then, only on Windows. I thought your list of failures would be down to just m3cc. What are they? - Jay ________________________________ > Date: Tue, 21 Jul 2009 17:59:47 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] status report on Windows XP > > > > > > > > Jay, > > > > Glad to hear the PkgInfo.txt is viable and being maintained. > > > > Right now, I just don't have the time and motivation to learn jscript. > > > > I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine. > > > > The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks. > > > > Regards, > > Randy > >>>> 7/21/2009 2:11 PM>>> > > Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform. > > > > The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it. > > > > You do have jscript installed and it is pretty easy to read and learn. > > > > pkginfo.txt is important and maintained, yes. > > I need to switch the python to it. > > > > Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is. > > > > Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate. > > > > - Jay (phone) > > > On Jul 21, 2009, at 8:02 AM, "Randy Coleburn"> wrote: > > > > > >>>> Jay K> 7/21/2009 4:05 AM>>> >>Bear in mind some features:> >> do-pkg (via sysinfo) does a good job of finding compiler/linker >> You can copy that, but I also intend to move it into the config files if I can. >> Though not sure e.g. path/lib/include-search is easy there. >> And I don't want the config files every time to launch a bunch of processes to do the probing. >> Maybe move the logic to cm3 itself. Maybe. > My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > > >> sets the version defines when building cm3, by reading the version file >> The python, .sh, and preexisting .cmd do that. You can copy the code out though. > I thought the version information was built into the compiler? > > >>Is a little more easily extended -- no builtin list of package groups, but not a big deal. >>Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >>Ditto for do-cm3-std.py wrapping do-pkg.py. > This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. > > >>The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >>and then improved things by introducing pkginfo.txt. > My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. > > >>Some of the generalizations aren't useful. >>I'm going to remove the purported support for PM3 and M3 from pylib.py for example. > >>My Python code is still missing a nifty feature that Olaf added to the .sh where you can >>pass extra parameters on to cm3. > My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. > > >>Yeah we do need to filter out more packages. >>The package list has grown since I last used the .cmd files and pylib.py has its own list, >>so I might not be building those packages on any platform. >>I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. > >>.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >>Again you might want to try writing JScript. It is much more natural. It can be slow >>but you aren't likely to notice here. And it is very portable to Windows. >>You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. > Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy > > From hosking at cs.purdue.edu Wed Jul 22 02:19:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 20:19:02 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A66005F.1E75.00D7.1@scires.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: I generally agree, but in this case we are probably dependent on a large number of C header files on the various different targets. Jay's efforts have reduced the burned of cloning C header files into Modula-3 interfaces. It is a fine line to tread though, and I think it is important to resist gratuitous rewrites into C code. In this case, I haven't had the chance to look at the code for Term.m3 and understand what is being attempted. On 21 Jul 2009, at 17:53, Randy Coleburn wrote: > Jay: > > I guess this topic is just a pet peeve of mine. > We tout Modula-3 as a systems programming language and that it has > all these great features that make it superior to languages that > lack them, yet when we "don't practice what we preach" and use > another language it weakens the argument. > > IMO, using C instead of Modula-3 is kind of like saying that we love > baseball, but we have to use soccer to play baseball the right way. > It just doesn't add up. > > I think we should always use Modula-3 in developing and enhancing > the CM3 system. > > I must also disagree with you and state that for a TRUE Modula-3 > fan, C is indeed "nasty." > > All that said, I haven't looked at the code in question here. I > simply commented on the idea of replacing M3 code with C code. > > Regards, > Randy > > >>> 7/21/2009 1:53 PM >>> > I might have left it able to be called safe. Honestly I look more for > human verifiable safety and correctness and it lacked those before and > now does not. If that coincides with machine verifable safety, great. > Either way you need C here for correctness and safety. It isn't > 'nasty'. Not using C here would be nasty. I think you have it > backwards. UNLESS the sizes and constants here are well known but > reading docs quickly I didn't see that. Unsafe does not imply not > portable. > > - Jay (phone) > > On Jul 21, 2009, at 9:03 AM, Tony Hosking > wrote: > > > Hear, hear! > > > > > > Sent from my iPhone > > > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > > wrote: > > > >> Granted, I see that Term.m3 is an UNSAFE module, so that by > >> definition means it is not portable. > >> Why though do we want to replace it by nasty C code where non- > >> portable stuff can be easily hidden? This is Modula-3. Why not > >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 > >> cents.) > >> --Randy > >> > >> >>> Jay Krell 7/21/2009 11:55 AM >>> > >> CVSROOT:/usr/cvs > >> Changes by:jkrell at birch.09/07/21 11:55:36 > >> > >> Added files: > >> cm3/caltech-parser/term/src/: TermC.c > >> > >> Log message: > >> initial copy of dangerous non portable Term.m3 to rewrite portably > >> and have it do nothing silently on Win32 which should suffice, or > >> if not, can probably be done better, specifically the MakeRaw > >> function > >> > >> > > > From jay.krell at cornell.edu Wed Jul 22 03:22:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 01:22:55 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: Until the kernels, libc, X-Windows, etc. are written in Modula-3, or come with Modula-3 *.i3 files provided by their maintainers, or perhaps completely stop changing, or perhaps we drop support for all but one target, all of which I predict to be never, it behooves us /significantly/ to interoperate with them via C. Otherwise you trade an impractical purist notion of using Modula-3 for portability and safety. The system is now tremendously more portable and safe with the replacement of a bunch of Modula-3 with far less portable clean safe C. It is true there is an extra layer when things are done this way, sometimes even extra copying. But it is worth it. Heck, it makes things more debuggable too because C tends to be more debuggable by gdb. Besides: The compiler front end is written in Modula-3. The garbage collector is written in Modula-3. The NT386 backend is written in Modula-3, and we should adapt that to all x86 targets. The compiler back-end is a //huge// piece of C (and M4, and Make, and Bourne shell...) The untraced heap is implemented in C. The "build scripts" are written in Bourne shell, Python, Cmd. They interact with a server written in at least Perl and C. You don't need the entire system to be in Modula-3 to prove that it is a "systems" language. You will never get there. Yes, I know people write web servers in other languages, including that cm3ide is essentially a web server written in Modula-3, but still, you won't get there. We should perhaps consider using the web server underpinnings of cm3ide to run modula3.elegosoft.com. Really. If it is close to already having the required functionality. We can actually have a bit more Modula-3 and less C. For example we could have our own untraced heap. We could implement Cstring.i3 ourselves in Modula-3. Besides all that, I've been using C a lot lately. I believe is far more tractable than most people think. Modula-3's safety and esp. its syntax get in my way. It isn't bad as, say, Java, but.. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Tue, 21 Jul 2009 20:19:02 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I generally agree, but in this case we are probably dependent on a > large number of C header files on the various different targets. > Jay's efforts have reduced the burned of cloning C header files into > Modula-3 interfaces. It is a fine line to tread though, and I think > it is important to resist gratuitous rewrites into C code. In this > case, I haven't had the chance to look at the code for Term.m3 and > understand what is being attempted. > > > On 21 Jul 2009, at 17:53, Randy Coleburn wrote: > >> Jay: >> >> I guess this topic is just a pet peeve of mine. >> We tout Modula-3 as a systems programming language and that it has >> all these great features that make it superior to languages that >> lack them, yet when we "don't practice what we preach" and use >> another language it weakens the argument. >> >> IMO, using C instead of Modula-3 is kind of like saying that we love >> baseball, but we have to use soccer to play baseball the right way. >> It just doesn't add up. >> >> I think we should always use Modula-3 in developing and enhancing >> the CM3 system. >> >> I must also disagree with you and state that for a TRUE Modula-3 >> fan, C is indeed "nasty." >> >> All that said, I haven't looked at the code in question here. I >> simply commented on the idea of replacing M3 code with C code. >> >> Regards, >> Randy >> >>>>> 7/21/2009 1:53 PM>>> >> I might have left it able to be called safe. Honestly I look more for >> human verifiable safety and correctness and it lacked those before and >> now does not. If that coincides with machine verifable safety, great. >> Either way you need C here for correctness and safety. It isn't >> 'nasty'. Not using C here would be nasty. I think you have it >> backwards. UNLESS the sizes and constants here are well known but >> reading docs quickly I didn't see that. Unsafe does not imply not >> portable. >> >> - Jay (phone) >> >> On Jul 21, 2009, at 9:03 AM, Tony Hosking >> wrote: >> >>> Hear, hear! >>> >>> >>> Sent from my iPhone >>> >>> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >>> wrote: >>> >>>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>>> definition means it is not portable. >>>> Why though do we want to replace it by nasty C code where non- >>>> portable stuff can be easily hidden? This is Modula-3. Why not >>>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>>> cents.) >>>> --Randy >>>> >>>>>>> Jay Krell 7/21/2009 11:55 AM>>> >>>> CVSROOT:/usr/cvs >>>> Changes by:jkrell at birch.09/07/21 11:55:36 >>>> >>>> Added files: >>>> cm3/caltech-parser/term/src/: TermC.c >>>> >>>> Log message: >>>> initial copy of dangerous non portable Term.m3 to rewrite portably >>>> and have it do nothing silently on Win32 which should suffice, or >>>> if not, can probably be done better, specifically the MakeRaw >>>> function >>>> >>>> >>> >> > From wagner at elegosoft.com Wed Jul 22 11:26:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 11:26:42 +0200 Subject: [M3devel] cm3ide HTTP server, was: Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: <20090722112642.vs5xve6934s8g4wk@mail.elegosoft.com> Quoting Jay K : > We should perhaps consider using the web server underpinnings of > cm3ide to run modula3.elegosoft.com. Really. If it is close to > already having the required functionality. No, it doesn't reach the area of complexity we usually expect in a web server nowadays. What we should do (which I intended to have done months ago :-/) is to setup a publicly accessible instance of the cm3ide GUI so people can play with it online. Some care must be taken though to not compromise our server... Anybody interested in doing this? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 22 16:06:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 16:06:45 +0200 Subject: [M3devel] tinderbox failures Message-ID: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Apart from four red boxes for new tinderbox clients, regression tests on niagara still fail: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248261714.32591 This used to work some days ago... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 16:28:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 14:28:30 +0000 Subject: [M3devel] tinderbox failures In-Reply-To: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Message-ID: Some of the new ones aren't terrible: LINUXLIBC6 failed the tests because it couldn't load dependent libraries. PPC_LINUX ran out of diskspace. SPARC32_LINUX looks ok. The problem on SOLgnu is it doesn't see the config file. Maybe my change yesterday will fix it? To always copy the config files? I'm very "timezone challenged". I never know when a Tinderbox run is in relation to my changes, and the changes column is no longer filled in since the server crash. :( How about we move cp_config_files earlier in upgrade.sh?? I can try that right now..I can't test it other than by watching the Tinderbox. If these are used with 5.4, hard to predict the result.. Go ahead with that? - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 16:06:45 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox failures > > Apart from four red boxes for new tinderbox clients, regression tests > on niagara still fail: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248261714.32591 > > This used to work some days ago... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 22 16:47:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 16:47:06 +0200 Subject: [M3devel] tinderbox failures In-Reply-To: References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Message-ID: <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> Quoting Jay K : > Some of the new ones aren't terrible: > LINUXLIBC6 failed the tests because it couldn't load dependent libraries. > PPC_LINUX ran out of diskspace. > SPARC32_LINUX looks ok. > > > The problem on SOLgnu is it doesn't see the config file. > Maybe my change yesterday will fix it? To always copy the config files? > I'm very "timezone challenged". I never know when a Tinderbox > run is in relation to my changes, and the changes column is no longer > filled in since the server crash. :( That's one of the things that just work in Hudson. I thought the release built was after your changes, or I wouldn't have sent the mail yet. > How about we move cp_config_files earlier in upgrade.sh?? > I can try that right now..I can't test it other than > by watching the Tinderbox. If these are used with 5.4, hard to predict > the result.. Go ahead with that? I don't understand what you want to achieve with that. But I cannot check right now. 5.4 has just one single cm3.cfg file, and no sub dirs. I told you we'd need to cope with that. But then it seems to have worked for FreeBSD on Hudson: see http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/changes and http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/16/consoleFull which start with === 2009-07-21 23:17:10 build cm3 core in /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4 with last release /ad0e/home/hudson/work/cm3-inst/luthien/rel-5.4.0 Critical Mass Modula-3 version 5.4.0 last updated: 2006-10-11 configuration: /ad0e/home/hudson/work/cm3-inst/luthien/current--release-build/bin/cm3.cfg I don't know if that's conclusive though... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 17:06:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 15:06:10 +0000 Subject: [M3devel] tinderbox failures In-Reply-To: <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> Message-ID: I need(ed) to read through/understand the scripts more. Yes, agreed, the configuration is best left alone when the preexisting cm3 is used -- which is always, now that I read it, it is copied either from lastok or last-rel. It should only be upgraded in association with cm3 being upgraded. Unless as a potshot to fix things, since the config files are fairly good and portable -- I think most of the stuff I removed was for pre-5.4 compat. Anyway, you can see in the log all the cp commands failed, because -v is not understood. Let's see how it goes now. My three new ones should go better, freed /lots/ of diskspace, made sure there were .a files in the lastok hand built installs, though odd that it should matter, the tests should use the new stuff. We'll see. I think I ran one of them lastrel by accident. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 16:47:06 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] tinderbox failures > > Quoting Jay K : > >> Some of the new ones aren't terrible: >> LINUXLIBC6 failed the tests because it couldn't load dependent libraries. >> PPC_LINUX ran out of diskspace. >> SPARC32_LINUX looks ok. >> >> >> The problem on SOLgnu is it doesn't see the config file. >> Maybe my change yesterday will fix it? To always copy the config files? >> I'm very "timezone challenged". I never know when a Tinderbox >> run is in relation to my changes, and the changes column is no longer >> filled in since the server crash. :( > > That's one of the things that just work in Hudson. > I thought the release built was after your changes, or I wouldn't have > sent the mail yet. > >> How about we move cp_config_files earlier in upgrade.sh?? >> I can try that right now..I can't test it other than >> by watching the Tinderbox. If these are used with 5.4, hard to predict >> the result.. Go ahead with that? > > I don't understand what you want to achieve with that. > But I cannot check right now. > > 5.4 has just one single cm3.cfg file, and no sub dirs. I told you > we'd need to cope with that. > > But then it seems to have worked for FreeBSD on Hudson: > > see > http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/changes > and > http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/16/consoleFull > > which start with > > === 2009-07-21 23:17:10 build cm3 core in > /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4 with last > release /ad0e/home/hudson/work/cm3-inst/luthien/rel-5.4.0 > Critical Mass Modula-3 version 5.4.0 > last updated: 2006-10-11 > configuration: > /ad0e/home/hudson/work/cm3-inst/luthien/current--release-build/bin/cm3.cfg > > I don't know if that's conclusive though... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From eiserlohpp at yahoo.com Wed Jul 22 17:53:09 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 22 Jul 2009 08:53:09 -0700 (PDT) Subject: [M3devel] m3middle compile failure (overrides) Message-ID: <982128.58200.qm@web56808.mail.re3.yahoo.com> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, but failed. The m3overrides file for m3middle, was recently changed, and now causes compilation failure. WAS: if not defined("BOOT") override("m3core", ROOT & "/m3-libs") override("libm3", ROOT & "/m3-libs") end NOW: include(ROOT & "/m3overrides") It is looking in the root of the entire source tree, for a non-existent m3overrides file, and quake rightly complains. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Wed Jul 22 17:55:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 15:55:46 +0000 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <982128.58200.qm@web56808.mail.re3.yahoo.com> References: <982128.58200.qm@web56808.mail.re3.yahoo.com> Message-ID: The file exists. cvs -z3 upd - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 08:53:09 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3middle compile failure (overrides) > > > I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, > but failed. > > > The m3overrides file for m3middle, was recently changed, > and now causes compilation failure. > > WAS: > if not defined("BOOT") > override("m3core", ROOT & "/m3-libs") > override("libm3", ROOT & "/m3-libs") > end > > > NOW: > include(ROOT & "/m3overrides") > > > It is looking in the root of the entire source tree, > for a non-existent m3overrides file, and quake rightly > complains. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Wed Jul 22 18:02:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 16:02:03 +0000 Subject: [M3devel] NT386 problem with C runtime/tools versions Message-ID: I just discovered that..well..if the user has a different version of Visual C++ tools/libraries than the distribution is built with..many scenarios don't work -- e.g. not using build_standalone. It should have worked better. Until/unless I work out something better here, I'd suggest we build multiple releases, one for each likely to be used toolset. 8.0/2005 and 9.0/2008 are probably a good mix currently. I guess in some ways this isn't surprising, IF any of the Modula-3 libraries traffic in either FILE* (fopen/fread/fwrite/fclose) or "int file" (open/close/read/write), but they might not. Or malloc/free, which they might. We might consider ensuring the untraced heap is via HeapAlloc(GetProcessHeap()) in order to be independent of the C runtime -- in general the C runtime dependencies probably can/should be limited, but this is another topic, another release. - Jay From jay.krell at cornell.edu Wed Jul 22 18:04:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 16:04:15 +0000 Subject: [M3devel] Tinderbox should always run tests? Message-ID: Olaf, is there any reason every Tinderbox run shouldn't run the tests? - Jay From rcoleburn at scires.com Wed Jul 22 18:06:16 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 22 Jul 2009 12:06:16 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> Message-ID: <4A670075.1E75.00D7.1@scires.com> Jay: I tried the python script, but it did not work for me. I installed python 2.6.2. Should I have used 3.1? There was a note about 3.1 not being compatible with some stuff. I discovered a problem in the PkgInfo.txt where the 3 juno packages didn't have the path "juno-2/" prepended, so I've fixed that and I've updated my local CVS copy to be current with the repository, and rebuilt everything using my script, e.g. "do-cm3 all clean buildship". The only packages from PkgInfo.txt that fail to build (i.e., cm3 exits with errorlevel >0) on Windows now are: m3-sys/m3cc caltech-parser/parserlib/parserlib/test Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on that package fails. Regards, Randy Coleburn >>> Jay K 7/21/2009 6:39 PM >>> I use the Python all the time on various platforms. It works. The .cmds I wrote I rarely use, and then, only on Windows. I thought your list of failures would be down to just m3cc. What are they? - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Wed Jul 22 18:34:10 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 22 Jul 2009 09:34:10 -0700 (PDT) Subject: [M3devel] m3middle compile failure (overrides) Message-ID: <817070.81781.qm@web56807.mail.re3.yahoo.com> Hi Jay, Peter said: >I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, but failed. Jay said: >The file exists. >cvs -z3 upd > >- Jay No it does not exist in the tarball. When I did a cvs update in my CVS tree, yes it is there, but not in the tarball. I downloaded a tarball, and attempted to build in that. The scripts used to build the tarballs look like they explicitly builds a list of files/directories to include and exclude. The toplevel m3overrides file is not listed in the build script, so does not get into ".tar-include". You added a file to the top level of the source tree, and the build script (make-src-dist-all.sh, and family) were not updated. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed Jul 22 18:56:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 18:56:48 +0200 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <817070.81781.qm@web56807.mail.re3.yahoo.com> References: <817070.81781.qm@web56807.mail.re3.yahoo.com> Message-ID: <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> Well, there are always side-effects to this kind of global changes. Jay, please fix the scripts. Thanks, Olaf Quoting Peter Eiserloh : > Hi Jay, > > > Peter said: >> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, > but failed. > > > Jay said: >> The file exists. >> cvs -z3 upd >> >> - Jay > > No it does not exist in the tarball. When I did a cvs update > in my CVS tree, yes it is there, but not in the tarball. > I downloaded a tarball, and attempted to build in that. > > The scripts used to build the tarballs look like they > explicitly builds a list of files/directories to include > and exclude. The toplevel m3overrides file is not listed > in the build script, so does not get into ".tar-include". > > You added a file to the top level of the source tree, and > the build script (make-src-dist-all.sh, and family) were > not updated. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 22 19:00:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 19:00:12 +0200 Subject: [M3devel] Tinderbox should always run tests? In-Reply-To: References: Message-ID: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> Quoting Jay K : > Olaf, is there any reason every Tinderbox run shouldn't run the tests? We don't want to run them both after the release- and the lastok- build (to save resources). It should be no problem to adapt the scripts for any specific setup (like I did on birch). If you don't run the release build, you should of course add running the tests after the lastok build. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 21:47:37 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 22 Jul 2009 12:47:37 -0700 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A670075.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> Message-ID: <050B1665-CAF7-4520-9613-B5EB0AD028E2@hotmail.com> I tried python 3.x once it didn't work. I stay with 2.x for now. - clean often does not work, I use realclean. I will check the test directory. You should be able to filter out m3cc. I might. - Jay (phone) On Jul 22, 2009, at 9:06 AM, "Randy Coleburn" wrote: > Jay: > > I tried the python script, but it did not work for me. I installed > python 2.6.2. Should I have used 3.1? There was a note about 3.1 > not being compatible with some stuff. > > I discovered a problem in the PkgInfo.txt where the 3 juno packages > didn't have the path "juno-2/" prepended, so I've fixed that and > I've updated my local CVS copy to be current with the repository, > and rebuilt everything using my script, e.g. "do-cm3 all clean > buildship". > > The only packages from PkgInfo.txt that fail to build (i.e., cm3 > exits with errorlevel >0) on Windows now are: > m3-sys/m3cc > caltech-parser/parserlib/parserlib/test > > Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on > that package fails. > > Regards, > Randy Coleburn > > >>> Jay K 7/21/2009 6:39 PM >>> > > I use the Python all the time on various platforms. It works. > The .cmds I wrote I rarely use, and then, only on Windows. > I thought your list of failures would be down to just m3cc. What are > they? > > - Jay From jay.krell at cornell.edu Wed Jul 22 22:35:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 20:35:36 +0000 Subject: [M3devel] Tinderbox should always run tests? In-Reply-To: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> References: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> Message-ID: Next question -- how to get the tests status to appear? I see the sample at the end of defs.sh -- call main | logfilter | mail. But how do integrate that with ./tinderbox-build cm3.build? Call them both one after the other? I don't see relevant tinderbox or cm3 in /etc/cron* /etc/cron*/* on birch. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 19:00:12 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: Tinderbox should always run tests? > > Quoting Jay K : > >> Olaf, is there any reason every Tinderbox run shouldn't run the tests? > > We don't want to run them both after the release- and the lastok- > build (to save resources). It should be no problem to adapt the > scripts for any specific setup (like I did on birch). > > If you don't run the release build, you should of course add running > the tests after the lastok build. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 22 22:37:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 20:37:15 +0000 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> References: <817070.81781.qm@web56807.mail.re3.yahoo.com> <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> Message-ID: oops, sorry, should be ok for the next set. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 18:56:48 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3middle compile failure (overrides) > > Well, there are always side-effects to this kind of global changes. > Jay, please fix the scripts. > > Thanks, > > Olaf > > Quoting Peter Eiserloh : > >> Hi Jay, >> >> >> Peter said: >>> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, >> but failed. >> >> >> Jay said: >>> The file exists. >>> cvs -z3 upd >>> >>> - Jay >> >> No it does not exist in the tarball. When I did a cvs update >> in my CVS tree, yes it is there, but not in the tarball. >> I downloaded a tarball, and attempted to build in that. >> >> The scripts used to build the tarballs look like they >> explicitly builds a list of files/directories to include >> and exclude. The toplevel m3overrides file is not listed >> in the build script, so does not get into ".tar-include". >> >> You added a file to the top level of the source tree, and >> the build script (make-src-dist-all.sh, and family) were >> not updated. >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 23 07:55:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 07:55:03 +0200 Subject: [M3devel] NT386 problem with C runtime/tools versions In-Reply-To: References: Message-ID: <20090723075503.bzhj08ps004c00oc@mail.elegosoft.com> Quoting Jay K : > > I just discovered that..well..if the user has a different version of > Visual C++ tools/libraries than the distribution is built > with..many scenarios don't work -- e.g. not using build_standalone. > It should have worked better. > Until/unless I work out something better here, I'd suggest we build > multiple releases, one for each likely to be used toolset. 8.0/2005 > and 9.0/2008 are probably a good mix currently. > > > I guess in some ways this isn't surprising, IF any of the Modula-3 > libraries traffic in either FILE* (fopen/fread/fwrite/fclose) or > "int file" (open/close/read/write), but they might not. Or > malloc/free, which they might. We might consider ensuring the > untraced heap is via HeapAlloc(GetProcessHeap()) in order to be > independent of the C runtime -- in general the C runtime > dependencies probably can/should be limited, but this is another > topic, another release. Please add these topics in trac to the roadmap for the next release. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 11:34:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 11:34:50 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A670075.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> Message-ID: <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Quoting Randy Coleburn : > The only packages from PkgInfo.txt that fail to build (i.e., cm3 > exits with errorlevel >0) on Windows now are: > m3-sys/m3cc > caltech-parser/parserlib/parserlib/test > > Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on > that package fails. Wrong (missing) depencencies or heavy quake hacking? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 15:42:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 15:42:53 +0200 Subject: [M3devel] CM3 Release Engineering Status Message-ID: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> I updated the roadmap in our trac https://projects.elego.de/cm3/roadmap and created several tickets, see https://projects.elego.de/cm3/timeline This morning I moved the RC2 tag to a position which should now be almost stable (hopefully), but I don't really know yet. Many tests are pending. Any help on resolving the tickets and other issues not yet recorded in trac will be appreciated. I'm not sure if we can cope with all the tasks during the weekend; I'll move the milestone date if necessary. Please write a ticket for every issue that is related to one of the release milestones (one on the formsedit crash is still missing, for example). Again, if you need access to trac, let me know; the web admin GUI is broken and I need to add accounts and passwords from the command line. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jul 23 17:10:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 23 Jul 2009 11:10:42 -0400 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> Message-ID: <4A6844E7.1E75.00D7.1@scires.com> Olaf: My browser is reporting a problem with the security certificate used for these web pages. I can work on "install.cmd" for you. I haven't had any crash with cm3ide. If someone can give details, I'll try to check into it. With regard to #1007, I already sent in the script you requested. Here it is again. Your script can be expressed in Windows .CMD format as follows: REM ---BEGIN--- @echo off for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p goto End :ShipIt echo ...shipping %1... pushd %1 cm3 -ship %SHIPARGS% popd echo. goto :EOF :End echo done @echo on REM ---END--- Of course, the REM lines at the beginning/end are optional, I just put them there to show start/end of the script. Also, you would want to replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of folders to be processed. You can separate them by blank spaces or semi-colons, but if you have a path with an embedded space, you will need to put double quotes around the path. FYI: If your list of paths is in a text file, there is another form of the FOR command that would work to process the list from that file. I don't mind writing .CMD files, so if you and Jay want some help in this area, I am willing to volunteer. Regards, Randy Coleburn >>> Olaf Wagner 7/23/2009 9:42 AM >>> I updated the roadmap in our trac https://projects.elego.de/cm3/roadmap and created several tickets, see https://projects.elego.de/cm3/timeline This morning I moved the RC2 tag to a position which should now be almost stable (hopefully), but I don't really know yet. Many tests are pending. Any help on resolving the tickets and other issues not yet recorded in trac will be appreciated. I'm not sure if we can cope with all the tasks during the weekend; I'll move the milestone date if necessary. Please write a ticket for every issue that is related to one of the release milestones (one on the formsedit crash is still missing, for example). Again, if you need access to trac, let me know; the web admin GUI is broken and I need to add accounts and passwords from the command line. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 23 17:21:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 23 Jul 2009 15:21:13 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <4A6844E7.1E75.00D7.1@scires.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: > My browser is reporting a problem with the security certificate used for these web pages. I reported that, for IE8. Workaround: Firefox or Opera. - Jay From wagner at elegosoft.com Thu Jul 23 18:13:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 18:13:14 +0200 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <4A6844E7.1E75.00D7.1@scires.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: <20090723181314.3csixgnyr4o84gsc@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > My browser is reporting a problem with the security certificate used > for these web pages. That may well be. I think you should be able to ignore those warnings. Admin resources are scarce currently, not to say non-existent :-/ I've got no problems with trac access with either Firefox or Opera. > I can work on "install.cmd" for you. > > I haven't had any crash with cm3ide. If someone can give details, I'll > try to check into it. > > With regard to #1007, I already sent in the script you requested. Here > it is again. I noticed you had send that, but haven't come round to include the generation in make-dist.sh. I'm rather collecting and recording all the tasks that need to be done (in spare minutes at my paid work). Thanks again, Olaf > Your script can be expressed in Windows .CMD format as follows: > > REM ---BEGIN--- > @echo off > for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p > goto End > > :ShipIt > echo ...shipping %1... > pushd %1 > cm3 -ship %SHIPARGS% > popd > echo. > goto :EOF > > :End > echo done > @echo on > REM ---END--- > > Of course, the REM lines at the beginning/end are optional, I just put > them there to show start/end of the script. Also, you would want to > replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of > folders to be processed. You can separate them by blank spaces or > semi-colons, but if you have a path with an embedded space, you will > need to put double quotes around the path. > > FYI: If your list of paths is in a text file, there is another form of > the FOR command that would work to process the list from that file. > > I don't mind writing .CMD files, so if you and Jay want some help in > this area, I am willing to volunteer. > > Regards, > Randy Coleburn > >>>> Olaf Wagner 7/23/2009 9:42 AM >>> > I updated the roadmap in our trac > > https://projects.elego.de/cm3/roadmap > > and created several tickets, see > > https://projects.elego.de/cm3/timeline > > This morning I moved the RC2 tag to a position which should > now be almost stable (hopefully), but I don't really know yet. > Many tests are pending. > > Any help on resolving the tickets and other issues not yet > recorded in trac will be appreciated. I'm not sure if we can cope > with all the tasks during the weekend; I'll move the milestone > date if necessary. > > Please write a ticket for every issue that is related to one of > the release milestones (one on the formsedit crash is still missing, > for example). > > Again, if you need access to trac, let me know; the web admin GUI > is broken and I need to add accounts and passwords from the command > line. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 18:16:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 18:16:08 +0200 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Quoting Jay K : > >> My browser is reporting a problem with the security certificate >> used for these web pages. > > I reported that, for IE8. > Workaround: Firefox or Opera. And you found no way to turn it off in Internet Explorer? Surely Microsoft cannot assume that the whole Internet is officially certified? We'd need to raise some funds if we wanted to do that for cm3... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 06:08:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 04:08:31 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Thu, 23 Jul 2009 18:16:08 +0200 > From: wagner > To: jay > CC: m3devel; m3-support; admins > Subject: RE: [M3devel] CM3 Release Engineering Status > > Quoting Jay K : > >> >>> My browser is reporting a problem with the security certificate >>> used for these web pages. >> >> I reported that, for IE8. >> Workaround: Firefox or Opera. > > And you found no way to turn it off in Internet Explorer? > > Surely Microsoft cannot assume that the whole Internet is > officially certified? We'd need to raise some funds if we wanted > to do that for cm3... > > Olaf I hadn't but now I have. The first error you get: There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority. The security certificate presented by this website was issued for a different website's address. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). More information You only get once per running IE and browsing to the site. Not a big deal. You can maybe add the certificate to some setting to ignore in future. I think this is the part you (Olaf and Randy) are referring to. The bigger problem is that once you ignore this, every single click in Trac brings up another message, about displaying a mix of secure/insecure content. I just found the fix to that: http://blogs.msdn.com/askie/archive/2009/05/14/mixed-content-and-internet-explorer-8-0.aspx A setting to for mixed content: enable, disable, prompt. Change from prompt to enable. I'm not sure if you can scope it to just modula3/elegosoft (maybe you can make a custom zone, add the sites, change the settings?) It sounds like it is only for IE8. That for IE7 there is no fix? Maybe for IE6 there was no prompt? I'm using IE8. Maybe you are supposed to replicate all the insecure stuff on the secure site? I don't know. - Jay From jay.krell at cornell.edu Fri Jul 24 06:45:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 04:45:42 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: > Surely Microsoft cannot assume that the whole Internet is > officially certified? We'd need to raise some funds if we wanted > to do that for cm3... > > Olaf How much? It looks like..verisign..cheapest option.. $600/year $1100/2 years (save $100) $1600/3 years (save $200) good enough? Can six people each put up $100, check payable to Olaf, he volunteers his time (or make it seven people, or $110 each), and we'll worry about it again in a year? I can. Or ignore it? Double the price for 128bit instead of 40bit. I don't understand the "extended validation, gren address bar". Shop around maybe it is availabe cheaper? Or just ignore it? Maybe they offer a discount for open source projects? I'll poke around a bit more.. GoDaddy seems to offer much better. Free for a year for open source projects, 256 bit, a $30 value. A $30 value, hm. So..if you don't want the bureacracy of being an official open source project.. They really do offer stuff starting at $30/year. Their most expensive option seems to be $240/year. Multi-year discounts range from 10% to 25%. So..just $30/year? Or free due to being open source? This sounds more viable and maybe worthwhile. Or just ignore it? - Jay From wagner at elegosoft.com Fri Jul 24 09:55:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 09:55:34 +0200 Subject: [M3devel] Trusted certificates for Elego's web services In-Reply-To: References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> I'll put this topic on the agenda of our next infrastructure meeting at Elego. It will be some time, since our 'prime administrator' is on a long vacation in the US. I've never really understood why I should feel more secure if a large enterprise whose procedures I don't know and can neither examine nor validate certifies that I bought just that certificate from them. Nor do I see it really necessary for those who don't engage in online shopping or trading. I do see that it's an interesting business though (financial perspective). However, it seems to become more and more expected that one has certificates from a trusted issuer, so it will affect all Elego customers, too. We'll have to get certificates for all our web servers, which will then include the CM3 one. I'll let you know if we can take over the costs :-) Let's ignore this issue for while... Olaf Quoting Jay K : >> Surely Microsoft cannot assume that the whole Internet is >> officially certified? We'd need to raise some funds if we wanted >> to do that for cm3... >> >> Olaf > > How much? > > > It looks like..verisign..cheapest option.. > $600/year > $1100/2 years (save $100) > $1600/3 years (save $200) > > good enough? > > Can six people each put up $100, check payable to Olaf, > he volunteers his time (or make it seven people, or $110 each), and we'll > worry about it again in a year? > I can. > > Or ignore it? > > Double the price for 128bit instead of 40bit. > > I don't understand the "extended validation, gren address bar". > > Shop around maybe it is availabe cheaper? > > Or just ignore it? > > Maybe they offer a discount for open source projects? > > I'll poke around a bit more.. > > > GoDaddy seems to offer much better. > Free for a year for open source projects, 256 bit, a $30 value. > A $30 value, hm. > > > So..if you don't want the bureacracy of being an official open > source project.. > They really do offer stuff starting at $30/year. > Their most expensive option seems to be $240/year. > Multi-year discounts range from 10% to 25%. > > > So..just $30/year? > Or free due to being open source? > > This sounds more viable and maybe worthwhile. Or just ignore it? > > > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 10:53:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:53:24 +0000 Subject: [M3devel] Hudson errors in cvs upd. Message-ID: A SCM change trigger started this job Building on master [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" U m3-libs/libm3/src/random/m3makefile U m3-libs/m3core/src/Csupport/m3makefile U m3-libs/m3core/src/time/POSIX/m3makefile ? m3-libs/unittest/AMD64_LINUX U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN ... cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' U m3-sys/m3middle/src/Target.i3 U m3-sys/m3middle/src/Target.m3 U m3-sys/m3middle/src/m3makefile U scripts/pkgmap.sh ? scripts/PKGS SCM check out aborted Finished: FAILURE I know I was thinking of deleting those directories but I don't think I did. - Jay From jay.krell at cornell.edu Fri Jul 24 10:57:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:57:09 +0000 Subject: [M3devel] Hudson errors out of diskspace Message-ID: Here's another: new source -> compiling ../FreeBSD4/cm3unix.c ../FreeBSD4/cm3unix.c:3: fatal error: error writing to /var/tmp/ccVwJXWF.s: No space left on device Hudson is looking like a big improvement though -- the last success, last failure columns, the list of changes in a build, the quick access to the full output. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: Hudson errors in cvs upd. > Date: Fri, 24 Jul 2009 08:53:24 +0000 > > > A SCM change trigger started this job > Building on master > [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" > U m3-libs/libm3/src/random/m3makefile > U m3-libs/m3core/src/Csupport/m3makefile > U m3-libs/m3core/src/time/POSIX/m3makefile > ? m3-libs/unittest/AMD64_LINUX > U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN > ... > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' > U m3-sys/m3middle/src/Target.i3 > U m3-sys/m3middle/src/Target.m3 > U m3-sys/m3middle/src/m3makefile > U scripts/pkgmap.sh > ? scripts/PKGS > SCM check out aborted > Finished: FAILURE > > > I know I was thinking of deleting those directories but I don't think I did. > > > - Jay From jay.krell at cornell.edu Fri Jul 24 10:57:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:57:50 +0000 Subject: [M3devel] Hudson errors out of diskspace Message-ID: also: /var/tmp/hudson46743.sh: line 11: /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4/scripts/do-cm3-all.sh: No such file or directory could be related to out of diskspace though. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: RE: Hudson errors out of diskspace > Date: Fri, 24 Jul 2009 08:57:09 +0000 > > > Here's another: > > > new source -> compiling ../FreeBSD4/cm3unix.c > ../FreeBSD4/cm3unix.c:3: fatal error: error writing to /var/tmp/ccVwJXWF.s: No space left on device > > > Hudson is looking like a big improvement though -- the last success, last failure columns, the list of changes in a build, the quick access to the full output. > > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; wagner at elegosoft.com >> Subject: Hudson errors in cvs upd. >> Date: Fri, 24 Jul 2009 08:53:24 +0000 >> >> >> A SCM change trigger started this job >> Building on master >> [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" >> U m3-libs/libm3/src/random/m3makefile >> U m3-libs/m3core/src/Csupport/m3makefile >> U m3-libs/m3core/src/time/POSIX/m3makefile >> ? m3-libs/unittest/AMD64_LINUX >> U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN >> ... >> cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' >> cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' >> U m3-sys/m3middle/src/Target.i3 >> U m3-sys/m3middle/src/Target.m3 >> U m3-sys/m3middle/src/m3makefile >> U scripts/pkgmap.sh >> ? scripts/PKGS >> SCM check out aborted >> Finished: FAILURE >> >> >> I know I was thinking of deleting those directories but I don't think I did. >> >> >> - Jay From stsp at elego.de Fri Jul 24 11:09:16 2009 From: stsp at elego.de (Stefan Sperling) Date: Fri, 24 Jul 2009 10:09:16 +0100 Subject: [M3devel] Trusted certificates for Elego's web services In-Reply-To: <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> Message-ID: <20090724090916.GC3671@jack.stsp.name> On Fri, Jul 24, 2009 at 09:55:34AM +0200, Olaf Wagner wrote: > We'll have to get certificates for all our web servers, which will > then include the CM3 one. I'll let you know if we can take over the > costs :-) > > Let's ignore this issue for while... There are local certificate issuers in Germany, too. E.g. Deutsche Telekom does it and their root CA even made it into Firefox now: https://bugzilla.mozilla.org/show_bug.cgi?id=378882 They might still be operating as opaquely as Verisign but maybe they are less expensive. And they'd probably be less complicated for elego to deal with than any issuer in the US. They've also signed certs for DFN members (German universities and research institutions). E.g. if you go here you can see a chain going up to Telekom: https://webmail.spline.inf.fu-berlin.de/ >>> Surely Microsoft cannot assume that the whole Internet is >>> officially certified? I have a feeling they'd like to, but more in terms of who controls the procotols being used on the net, not necessarily with respect to SSL certs. That said, newer Firefox versions have also been pushing the user experience with self-signed certs far down in an attempt to get website admins to get their certs signed. Stefan From wagner at elegosoft.com Fri Jul 24 11:44:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 11:44:38 +0200 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: References: Message-ID: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Quoting Jay K : > Here's another: > > new source -> compiling ../FreeBSD4/cm3unix.c > ../FreeBSD4/cm3unix.c:3: fatal error: error writing to > /var/tmp/ccVwJXWF.s: No space left on device That was on my home machine because core dumps from m3tests were accumulating in /var/tmp. I've now set the core dump limit to 0 for those jobs. > Hudson is looking like a big improvement though -- the last success, > last failure columns, the list of changes in a build, the quick > access to the full output. Yes. I've been using it for about half a year now, and apart from the fact that it's resource hungry and sometimes slow, it's easy to use and configure. And you find a plug-in for almost everything. Since yesterday afternoon all necessary plug-ins for interaction with other servers should be installed. I've just moved the crontab jobs from user m3 on birch to hudson, see http://hudson.modula3.com:8080/view/m3-www-support/. My network connection is very unstable currently, so more failures are to be expected. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 12:44:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 10:44:06 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure Message-ID: I'm seeing wierd stuff. On PPC_LINUX. Compiling some files hangs. Such as M3Front.m3. It is actually looping forever in Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") which, you know, other than feeding it bad data, or corrupting its stack when it calls out to our lock/unlock, we can't mess up. I can watch what strings it gets on other systems and/or make a standalone case that hangs. While investigating this I hit control-c on a cm3 and hit: new source -> compiling SchedulerPosix.i3 (hung here) *** *** runtime error: *** failed. *** file "..\src\runtime\common\RTCollector.m3", line 1087 *** Aborted PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = BEGIN WHILE h < he DO line 1087 Maybe we don't deal with control-c at arbitrary points?? I was able to reproduce this assertion failure twice in a row.. though it moved to line 1089 the second time. PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = BEGIN WHILE h < he DO IF h.gray THEN line 1089 I verified that the hang compiling SchedulerPosix.i3 is also related to floating point conversion. This time in m3_dtoa. I will look further. Maybe my config file changes..but seems odd.. - Jay - Jay From jay.krell at cornell.edu Fri Jul 24 12:48:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 10:48:09 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: References: Message-ID: sorry, nevermind. It reproed on SOLgnu and then I found the problem. It's good to test little and big endian systems. I had broken all big endian systems. Should be ok now. I'll proceed to try to repro the formsedit crash. :) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 24 Jul 2009 10:44:06 +0000 > Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure > > > I'm seeing wierd stuff. > > On PPC_LINUX. From jay.krell at cornell.edu Fri Jul 24 13:41:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 11:41:25 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Message-ID: This should be fixed now. I assume it was broken on all platforms. -clean doesn't work well. Maybe time to make -clean just do the same as -realclean? - Jay ---------------------------------------- > Date: Thu, 23 Jul 2009 11:34:50 +0200 > From: wagner@ > To: m3devel@ > Subject: Re: [M3devel] status report on Windows XP > > Quoting Randy Coleburn : > >> The only packages from PkgInfo.txt that fail to build (i.e., cm3 >> exits with errorlevel>0) on Windows now are: >> m3-sys/m3cc >> caltech-parser/parserlib/parserlib/test >> >> Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on >> that package fails. > > Wrong (missing) depencencies or heavy quake hacking? > > Olaf > -- From wagner at elegosoft.com Fri Jul 24 13:56:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 13:56:15 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Message-ID: <20090724135615.n9htefpvkw4gogw8@mail.elegosoft.com> Quoting Jay K : > > This should be fixed now. > I assume it was broken on all platforms. > -clean doesn't work well. > Maybe time to make -clean just do the same as -realclean? I wouldn't mind that. Perhaps others do? Olaf > ---------------------------------------- >> Date: Thu, 23 Jul 2009 11:34:50 +0200 >> From: wagner@ >> To: m3devel@ >> Subject: Re: [M3devel] status report on Windows XP >> >> Quoting Randy Coleburn : >> >>> The only packages from PkgInfo.txt that fail to build (i.e., cm3 >>> exits with errorlevel>0) on Windows now are: >>> m3-sys/m3cc >>> caltech-parser/parserlib/parserlib/test >>> >>> Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on >>> that package fails. >> >> Wrong (missing) depencencies or heavy quake hacking? >> >> Olaf >> -- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 14:04:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 12:04:42 +0000 Subject: [M3devel] bourne shell error on Solaris tinderbox Message-ID: Tinderbox on Solaris: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? unexpected Perl or Python would be more portable perhaps. Or Modula-3? (Seriously: Python). - Jay From wagner at elegosoft.com Fri Jul 24 15:17:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 15:17:07 +0200 Subject: [M3devel] bourne shell error on Solaris tinderbox In-Reply-To: References: Message-ID: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> Quoting Jay K : > Tinderbox on Solaris: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 > > /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? > unexpected Sorry for that. Solaris has ksh, which understands POSIX command substitution, but other systems won't have that. Can we assume bash, or should I just replace all $() by backquotes again? > Perl or Python would be more portable perhaps. Or Modula-3? > (Seriously: Python). I don't want to have that big dependency for all tests... Otherwise I'd agree: always use Python if possible. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jul 24 16:06:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 24 Jul 2009 10:06:52 -0400 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: References: Message-ID: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> Yeah, I don't think control C works reasonably for all points in GC. Perhaps just eliminate the signal handler? Not sure. On 24 Jul 2009, at 06:44, Jay K wrote: > > I'm seeing wierd stuff. > > On PPC_LINUX. > > Compiling some files hangs. > Such as M3Front.m3. > > It is actually looping forever in > > Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") > > > which, you know, other than feeding it bad data, or corrupting > its stack when it calls out to our lock/unlock, we can't mess up. > > > I can watch what strings it gets on other systems and/or make > a standalone case that hangs. > > > While investigating this I hit control-c on a cm3 and hit: > > > new source -> compiling SchedulerPosix.i3 (hung here) > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > Aborted > > > > PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = > BEGIN > WHILE h < he DO > > line 1087 > > > Maybe we don't deal with control-c at arbitrary points?? > > > I was able to reproduce this assertion failure twice in a row.. > though it moved to line 1089 the second time. > > > > PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = > BEGIN > WHILE h < he DO > > > IF h.gray THEN > line 1089 > > > I verified that the hang compiling SchedulerPosix.i3 is also related > to floating point conversion. > This time in m3_dtoa. > > > I will look further. > Maybe my config file changes..but seems odd.. > > - Jay > > > - Jay > > From jay.krell at cornell.edu Fri Jul 24 16:08:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 14:08:08 +0000 Subject: [M3devel] bourne shell error on Solaris tinderbox In-Reply-To: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> References: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> Message-ID: Whatever works automatically or with little documented/errored fuss. (use #!/bin/bash and there'll be a clear error.) I doubt bash is on most systems by default. I figure if you have to use something that isn't installed by default, might as well be Python. (Esp. once I get it working on MIPS64_OPENBSD! Probably just have to turn off libffi.) - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 15:17:07 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: bourne shell error on Solaris tinderbox > > Quoting Jay K : > >> Tinderbox on Solaris: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 >> >> /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? >> unexpected > > Sorry for that. Solaris has ksh, which understands POSIX command > substitution, but other systems won't have that. > Can we assume bash, or should I just replace all $() by backquotes > again? > >> Perl or Python would be more portable perhaps. Or Modula-3? >> (Seriously: Python). > > I don't want to have that big dependency for all tests... > Otherwise I'd agree: always use Python if possible. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 24 16:11:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 14:11:41 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> References: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> Message-ID: Right..so I had a big blatant bug..but the next thing to try is feeding this string to the convert functions through a "safe" path and see if it hangs.. and address the control-c issue maybe (if it is process kill though, fix is to just run less code..) >> Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") (note that hotmail ruined the pragmas due to the angle brackets..) and I'll have to find what the parameter to m3_dtoawas. Btw, the bug was, quake: if defined("FOO") if equal("FOO", "BAR") something else something else instead of if defined("FOO") if equal(FOO, "BAR") - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure > Date: Fri, 24 Jul 2009 10:06:52 -0400 > > Yeah, I don't think control C works reasonably for all points in GC. > Perhaps just eliminate the signal handler? Not sure. > > > > On 24 Jul 2009, at 06:44, Jay K wrote: > >> >> I'm seeing wierd stuff. >> >> On PPC_LINUX. >> >> Compiling some files hangs. >> Such as M3Front.m3. >> >> It is actually looping forever in >> >> Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") >> >> >> which, you know, other than feeding it bad data, or corrupting >> its stack when it calls out to our lock/unlock, we can't mess up. >> >> >> I can watch what strings it gets on other systems and/or make >> a standalone case that hangs. >> >> >> While investigating this I hit control-c on a cm3 and hit: >> >> >> new source -> compiling SchedulerPosix.i3 (hung here) >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >> *** >> Aborted >> >> >> >> PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = >> BEGIN >> WHILE h < he DO >> >> line 1087 >> >> >> Maybe we don't deal with control-c at arbitrary points?? >> >> >> I was able to reproduce this assertion failure twice in a row.. >> though it moved to line 1089 the second time. >> >> >> >> PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = >> BEGIN >> WHILE h < he DO >> >> >> IF h.gray THEN >> line 1089 >> >> >> I verified that the hang compiling SchedulerPosix.i3 is also related >> to floating point conversion. >> This time in m3_dtoa. >> >> >> I will look further. >> Maybe my config file changes..but seems odd.. >> >> - Jay >> >> >> - Jay >> >> > From hosking at cs.purdue.edu Fri Jul 24 16:14:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 24 Jul 2009 10:14:08 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090724071308.62663CC81C@birch.elegosoft.com> References: <20090724071308.62663CC81C@birch.elegosoft.com> Message-ID: <6309A64A-4FD5-4EF6-B58E-7E791F1E6DF7@cs.purdue.edu> On 24 Jul 2009, at 09:13, Jay Krell wrote: > Log message: > VAX was actually Ultrix apparently, not VMS, so remove VMS entry > until we have an actual VMS port Very amusing! :-) From rcoleburn at scires.com Fri Jul 24 17:47:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 24 Jul 2009 11:47:10 -0400 Subject: [M3devel] Hudson question In-Reply-To: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: <4A699EF1.1E75.00D7.1@scires.com> Olaf: If we switch to Hudson, does that offer any improvement in the Windows arena? We haven't been able to get Tinderbox to work for Windows. I don't mind hosting something for Windows to do the tests if that will help. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 24 18:17:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 18:17:29 +0200 Subject: [M3devel] Hudson question In-Reply-To: <4A699EF1.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> Message-ID: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > If we switch to Hudson, does that offer any improvement in the Windows arena? > > We haven't been able to get Tinderbox to work for Windows. > > I don't mind hosting something for Windows to do the tests if that will help. Well, yes and no ;-) Hudson itself should be as easy to install on Windows as on Unix, as it's completely written in Java. You just download the hudson.war file and start it with java -jar hudson.war. Java should be at least a recent 1.6 distribution. You can just try that and play around with the server if you like. The regression test scripts are all written in Bourne shell syntax, so you'd need Cygwin to run those again. There are probably a few quirks left to make them really work on Windows. Perhaps the Interix POSIX environment Jay has told about may be better suited, but I don't know. In the Hudson setup on birch and luthien I've used parts of the regression scripts for Tinderbox. If we want the test scripts to be the same on all systems, it may still be difficult. On the other hand, we could start with a much simpler setup on Windows. Begin with just one test job that checks out and compiles everything. That should be easy to achieve. I don't know if you can use the cmd scripts in Hudson on Windows, but I assume you can. If that works, we could start with transferring your build results to the Hudson server on birch. Or you could allow birch to control your Hudson installation as a slave server. Does that sound feasible? Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 01:12:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:12:30 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: It doesn't likely make a difference. Before you needed Cygwin or Interix. Now you need Cygwin or Interix, and probably Java. Java will probably be a sticking point on various platforms, but the gains are also very nice where it is available. I see there has been work done on an assembly-free Java VM since Sun open sourced their VM, so that promises increased portability. (One wonders some about the Critical Mass VM). Writing more .cmd isn't going to help anything imho. It's just more hard to maintain code that someone will have to maintain in parallel to Olaf's .sh. Which is why I favor Python -- portable, no duplicated effort. "Hard to main" as it, sure, it is easy to get started, but what happens when you decide you need an array, or a hash table? Or any of a number of basic programming constructs? Ok, I guess you have while loops, using goto. Local variables. At least that are strings. Everything is a string. cmd has one or two surprisingly powerfuli features, such as for /f and set /a. If you can't do your work with them, you can't do it. sh is a bit more portable than Python, but not by much and imho at too large a cost in maintainability/generality. It still seems to me like a string based language that can't do much, but I admit I'm not practised in it. (I am very practised in .cmd.) You know, the fact that expression evaluation is in some mix of the "[" command and maybe in sh itself. That people write if xxx true else yyy instead of if not xxx yyy. The fact that Solaris is different. The fact that quoting is needed in various places. Quoting always bothers me. It is hard to predict how many levels of unquoting will be done. I suspect cmd, sh, and Tcl are all in the same overly string based boat. For example in Tcl, { } appear to have the same meaning as in C and C++, good, but in fact they are escape characters, very wierd and bad. Cygwin and Interix both probably work fine. Someone just has to set them up and run them. Consider Cygwin and Interix almost the same. Interix is much faster, if you are calling fork a lot. Cygwin is slightly more compatible with Linux/Posix. Interix has a few ways in which is resembles Linux/Posix more though, such as not using extensions on executables, using ".so", supporting runpath. I think with Cygwin 1.7, both it and Interix go to extreme of supporting backward slash and colon in paths. Interix actually ors in 0xFF00 to such characters but it is transparent to Interix code. Or maybe that's what Cygwin does. I don't remember. It is completely non transparent and discoverable if you look at the results from Win32. Interix probably a larger download, because the part that is mostly "built in" is basically nothing, just some infrastructure and very few utilities. I don't think there is even sh or ksh. Everything else is one large download. On XP nothing is "builtin", there is just one large download. "builtin" is on Server 2003 R2, Vista, Server 2008, etc. (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 18:17:29 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson question > > Quoting Randy Coleburn : > >> Olaf: >> >> If we switch to Hudson, does that offer any improvement in the Windows arena? >> >> We haven't been able to get Tinderbox to work for Windows. >> >> I don't mind hosting something for Windows to do the tests if that will help. > > Well, yes and no ;-) > > Hudson itself should be as easy to install on Windows as on Unix, > as it's completely written in Java. You just download the hudson.war > file and start it with java -jar hudson.war. Java should be at least > a recent 1.6 distribution. You can just try that and play around with > the server if you like. > > The regression test scripts are all written in Bourne shell syntax, > so you'd need Cygwin to run those again. There are probably a few > quirks left to make them really work on Windows. Perhaps the Interix > POSIX environment Jay has told about may be better suited, but I don't > know. > > In the Hudson setup on birch and luthien I've used parts of the > regression scripts for Tinderbox. If we want the test scripts to be > the same on all systems, it may still be difficult. > > On the other hand, we could start with a much simpler setup on Windows. > Begin with just one test job that checks out and compiles everything. > That should be easy to achieve. I don't know if you can use the cmd > scripts in Hudson on Windows, but I assume you can. If that works, > we could start with transferring your build results to the Hudson > server on birch. Or you could allow birch to control your Hudson > installation as a slave server. > > Does that sound feasible? > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sat Jul 25 01:16:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:16:33 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: [truncated as usual..] ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Hudson question > Date: Fri, 24 Jul 2009 23:12:30 +0000 > > > It doesn't likely make a difference. > > > Before you needed Cygwin or Interix. > Now you need Cygwin or Interix, and probably Java. > Java will probably be a sticking point on various platforms, > but the gains are also very nice where it is available. > I see there has been work done on an assembly-free Java VM > since Sun open sourced their VM, so that promises increased portability. > (One wonders some about the Critical Mass VM). > > > Writing more .cmd isn't going to help anything imho. > It's just more hard to maintain code that someone > will have to maintain in parallel to Olaf's .sh. > Which is why I favor Python -- portable, no duplicated effort. > > > "Hard to main" as it, sure, it is easy to get started, but > what happens when you decide you need an array, or a hash table? > Or any of a number of basic programming constructs? > Ok, I guess you have while loops, using goto. > Local variables. At least that are strings. Everything is a string. > cmd has one or two surprisingly powerfuli features, such as for /f > and set /a. If you can't do your work with them, you can't do it. > sh is a bit more portable than Python, but not by much and > imho at too large a cost in maintainability/generality. > It still seems to me like a string based language that can't do much, > but I admit I'm not practised in it. (I am very practised in .cmd.) > > > You know, the fact that expression evaluation is in some mix of the "[" command > and maybe in sh itself. That people write if xxx true else yyy instead > of if not xxx yyy. > The fact that Solaris is different. > The fact that quoting is needed in various places. > Quoting always bothers me. It is hard to predict how many levels > of unquoting will be done. > I suspect cmd, sh, and Tcl are all in the same overly string based boat. > For example in Tcl, { } appear to have the same meaning as in C and C++, good, > but in fact they are escape characters, very wierd and bad. > > > Cygwin and Interix both probably work fine. > Someone just has to set them up and run them. > > > Consider Cygwin and Interix almost the same. > Interix is much faster, if you are calling fork a lot. > Cygwin is slightly more compatible with Linux/Posix. > > > Interix has a few ways in which is resembles Linux/Posix more though, > such as not using extensions on executables, using ".so", supporting > runpath. > > > I think with Cygwin 1.7, both it and Interix go to extreme > of supporting backward slash and colon in paths. > Interix actually ors in 0xFF00 to such characters but > it is transparent to Interix code. Or maybe that's what > Cygwin does. I don't remember. It is completely non > transparent and discoverable if you look at the results from Win32. > > > Interix probably a larger download, because the > part that is mostly "built in" is basically nothing, > just some infrastructure and very few utilities. > I don't think there is even sh or ksh. > Everything else is one large download. > > > On XP nothing is "builtin", there is just one large download. > "builtin" is on Server 2003 R2, Vista, Server 2008, etc. > > > (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. > But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) > > > - Jay > > > ---------------------------------------- >> Date: Fri, 24 Jul 2009 18:17:29 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Hudson question >> >> Quoting Randy Coleburn : >> >>> Olaf: >>> >>> If we switch to Hudson, does that offer any improvement in the Windows arena? >>> >>> We haven't been able to get Tinderbox to work for Windows. >>> >>> I don't mind hosting something for Windows to do the tests if that will help. >> >> Well, yes and no ;-) >> >> Hudson itself should be as easy to install on Windows as on Unix, >> as it's completely written in Java. You just download the hudson.war >> file and start it with java -jar hudson.war. Java should be at least >> a recent 1.6 distribution. You can just try that and play around with >> the server if you like. >> >> The regression test scripts are all written in Bourne shell syntax, >> so you'd need Cygwin to run those again. There are probably a few >> quirks left to make them really work on Windows. Perhaps the Interix >> POSIX environment Jay has told about may be better suited, but I don't >> know. >> >> In the Hudson setup on birch and luthien I've used parts of the >> regression scripts for Tinderbox. If we want the test scripts to be >> the same on all systems, it may still be difficult. >> >> On the other hand, we could start with a much simpler setup on Windows. >> Begin with just one test job that checks out and compiles everything. >> That should be easy to achieve. I don't know if you can use the cmd >> scripts in Hudson on Windows, but I assume you can. If that works, >> we could start with transferring your build results to the Hudson >> server on birch. Or you could allow birch to control your Hudson >> installation as a slave server. >> >> Does that sound feasible? >> >> Regards, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sat Jul 25 01:18:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:18:17 +0000 Subject: [M3devel] FW: Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: [truncated again, one more try then I give up..] > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] Hudson question >> Date: Fri, 24 Jul 2009 23:12:30 +0000 >> >> >> It doesn't likely make a difference. >> >> >> Before you needed Cygwin or Interix. >> Now you need Cygwin or Interix, and probably Java. >> Java will probably be a sticking point on various platforms, >> but the gains are also very nice where it is available. >> I see there has been work done on an assembly-free Java VM >> since Sun open sourced their VM, so that promises increased portability. >> (One wonders some about the Critical Mass VM). >> >> >> Writing more .cmd isn't going to help anything imho. >> It's just more hard to maintain code that someone >> will have to maintain in parallel to Olaf's .sh. >> Which is why I favor Python -- portable, no duplicated effort. >> >> >> "Hard to main" as it, sure, it is easy to get started, but >> what happens when you decide you need an array, or a hash table? >> Or any of a number of basic programming constructs? >> Ok, I guess you have while loops, using goto. >> Local variables. At least that are strings. Everything is a string. >> cmd has one or two surprisingly powerfuli features, such as for /f >> and set /a. If you can't do your work with them, you can't do it. >> sh is a bit more portable than Python, but not by much and >> imho at too large a cost in maintainability/generality. >> It still seems to me like a string based language that can't do much, >> but I admit I'm not practised in it. (I am very practised in .cmd.) >> >> >> You know, the fact that expression evaluation is in some mix of the "[" command >> and maybe in sh itself. That people write if xxx true else yyy instead >> of if not xxx yyy. >> The fact that Solaris is different. >> The fact that quoting is needed in various places. >> Quoting always bothers me. It is hard to predict how many levels >> of unquoting will be done. >> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >> but in fact they are escape characters, very wierd and bad. >> >> >> Cygwin and Interix both probably work fine. >> Someone just has to set them up and run them. >> >> >> Consider Cygwin and Interix almost the same. >> Interix is much faster, if you are calling fork a lot. >> Cygwin is slightly more compatible with Linux/Posix. >> >> >> Interix has a few ways in which is resembles Linux/Posix more though, >> such as not using extensions on executables, using ".so", supporting >> runpath. >> >> >> I think with Cygwin 1.7, both it and Interix go to extreme >> of supporting backward slash and colon in paths. >> Interix actually ors in 0xFF00 to such characters but >> it is transparent to Interix code. Or maybe that's what >> Cygwin does. I don't remember. It is completely non >> transparent and discoverable if you look at the results from Win32. >> >> >> Interix probably a larger download, because the >> part that is mostly "built in" is basically nothing, >> just some infrastructure and very few utilities. >> I don't think there is even sh or ksh. >> Everything else is one large download. >> >> >> On XP nothing is "builtin", there is just one large download. >> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >> >> >> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >> >> >> - Jay >> >> >> ---------------------------------------- [deliberate snip] From jay.krell at cornell.edu Sat Jul 25 01:30:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:30:23 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: Interix is actually multiple downloads. The first one has a lot of bugs, like gcc never working on systems that support the "no execute" bit, and the NFS server or client crashing the machine (bugcheck, blue screen). To get updates, instead of the usual windowsupdate.microsoft.com, you have to go a special web page, type in the KB articles that you discover searching the web, recieve a link to a password-protected executable/.zip, you get the current password and the next one. If you wait too long, or gosh, want to reinstall everything, officially you need to go through the ridiculuous rigamarole again. Though actually what you can do is extract the .exes/.zips once and keep those around. The first large download from Microsoft gives you a bunch of "utilities", like sh, ksh, gcc, ld, bash. There is also a large second download from interopsystems.com or such to get more and updated utilities. That's where I got e.g. Python. There is a small problem compiling Python out of the box, something around filesystem case sensitivity, even though Interix does offer case sensitive file system, there seems to be a small problem with it. Python detects the case sensitive file system, in which case it is willing to put Python directory and python executable file next to each other, but when it later runs "sh -c ./python", that tries to run the directory and gets access denied. There is a code path in configure for case insensitive, which alters the paths, presumably the workaround is to set the environment variable to force the configure check. Heck, they could just always do it that way.. Presumably starting with a base of Server 2003 R2 or Vista or newer is better, but the above is the experience on XP. So, it is kind of a pain on XP, but the result is way way faster than Cygwin. The cost of fork on Cygwin is huge and definitely occurs. I'm still in the habit of using Cygwin though, like for cvs. Cygwin is multiple downloads in a sense, but they have a fairly nice setup that will do them all. I think the interopsystems.com download does lead pretty directly to X Windows too via a separate package. I just have to remind folks that if the main goal is just forward slashes in file system paths, NT386 works fine there now. Granted, I understand, you also want sh, X windows, 64bit LONGINT, optimizing backend backend (MinGW can deliver the last two). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: FW: [M3devel] Hudson question > Date: Fri, 24 Jul 2009 23:18:17 +0000 > > > [truncated again, one more try then I give up..] > >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>> Subject: RE: [M3devel] Hudson question >>> Date: Fri, 24 Jul 2009 23:12:30 +0000 >>> >>> >>> It doesn't likely make a difference. >>> >>> >>> Before you needed Cygwin or Interix. >>> Now you need Cygwin or Interix, and probably Java. >>> Java will probably be a sticking point on various platforms, >>> but the gains are also very nice where it is available. >>> I see there has been work done on an assembly-free Java VM >>> since Sun open sourced their VM, so that promises increased portability. >>> (One wonders some about the Critical Mass VM). >>> >>> >>> Writing more .cmd isn't going to help anything imho. >>> It's just more hard to maintain code that someone >>> will have to maintain in parallel to Olaf's .sh. >>> Which is why I favor Python -- portable, no duplicated effort. >>> >>> >>> "Hard to main" as it, sure, it is easy to get started, but >>> what happens when you decide you need an array, or a hash table? >>> Or any of a number of basic programming constructs? >>> Ok, I guess you have while loops, using goto. >>> Local variables. At least that are strings. Everything is a string. >>> cmd has one or two surprisingly powerfuli features, such as for /f >>> and set /a. If you can't do your work with them, you can't do it. >>> sh is a bit more portable than Python, but not by much and >>> imho at too large a cost in maintainability/generality. >>> It still seems to me like a string based language that can't do much, >>> but I admit I'm not practised in it. (I am very practised in .cmd.) >>> >>> >>> You know, the fact that expression evaluation is in some mix of the "[" command >>> and maybe in sh itself. That people write if xxx true else yyy instead >>> of if not xxx yyy. >>> The fact that Solaris is different. >>> The fact that quoting is needed in various places. >>> Quoting always bothers me. It is hard to predict how many levels >>> of unquoting will be done. >>> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >>> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >>> but in fact they are escape characters, very wierd and bad. >>> >>> >>> Cygwin and Interix both probably work fine. >>> Someone just has to set them up and run them. >>> >>> >>> Consider Cygwin and Interix almost the same. >>> Interix is much faster, if you are calling fork a lot. >>> Cygwin is slightly more compatible with Linux/Posix. >>> >>> >>> Interix has a few ways in which is resembles Linux/Posix more though, >>> such as not using extensions on executables, using ".so", supporting >>> runpath. >>> >>> >>> I think with Cygwin 1.7, both it and Interix go to extreme >>> of supporting backward slash and colon in paths. >>> Interix actually ors in 0xFF00 to such characters but >>> it is transparent to Interix code. Or maybe that's what >>> Cygwin does. I don't remember. It is completely non >>> transparent and discoverable if you look at the results from Win32. >>> >>> >>> Interix probably a larger download, because the >>> part that is mostly "built in" is basically nothing, >>> just some infrastructure and very few utilities. >>> I don't think there is even sh or ksh. >>> Everything else is one large download. >>> >>> >>> On XP nothing is "builtin", there is just one large download. >>> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >>> >>> >>> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >>> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- > [deliberate snip] > From rcoleburn at scires.com Sat Jul 25 02:43:13 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 24 Jul 2009 20:43:13 -0400 Subject: [M3devel] FW: Hudson question In-Reply-To: References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: <4A6A1C90.1E75.00D7.1@scires.com> Jay: I know you are pro Python and some scripts are in python and some scripts are in .sh and there is cygwin etc etc, but let me list why I think we need CMD on Windows: 1. CMD comes with Windows out-of-the-box. No extra config/install is required. 2. I want to be able to launch a CMD window and use the cm3 command line tools to build Modula-3 packages. I also want to be able to run Modula-3 programs without need of any other tools except what comes with Windows by default. Now the latter isn't exactly possible if you are dependent on the .NET framework, but most systems have .NET anyway because Microsoft has pushed it out through online updates. 3. I continue to experience problems with cygwin, python, etc. because the setup in each is slightly different and there are dependencies that are not obvious. If you succeed in installing cm3 using cygwin, it isn't always possible to build/run packages from CMD. I haven't been able to get the python scripts to work for me, despite installing python. 4. CM3IDE launches the native shell to run the cm3 command line tools. On Windows, this shell is CMD. We need to preserve this functionality. 5. I have provided various CMD scripts in the repository and I've been keeping these up-to-date. I don't mind continuing to do this. 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. 7. Whatever automated test environment we provide on Windows must work in the native shell in order to prove that stuff is working in that shell. If you use cygwin or some other shell, that doesn't mean it will work in CMD. Regards, Randy Coleburn >>> Jay K 7/24/2009 7:18 PM >>> [truncated again, one more try then I give up..] > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] Hudson question >> Date: Fri, 24 Jul 2009 23:12:30 +0000 >> >> >> It doesn't likely make a difference. >> >> >> Before you needed Cygwin or Interix. >> Now you need Cygwin or Interix, and probably Java. >> Java will probably be a sticking point on various platforms, >> but the gains are also very nice where it is available. >> I see there has been work done on an assembly-free Java VM >> since Sun open sourced their VM, so that promises increased portability. >> (One wonders some about the Critical Mass VM). >> >> >> Writing more .cmd isn't going to help anything imho. >> It's just more hard to maintain code that someone >> will have to maintain in parallel to Olaf's .sh. >> Which is why I favor Python -- portable, no duplicated effort. >> >> >> "Hard to main" as it, sure, it is easy to get started, but >> what happens when you decide you need an array, or a hash table? >> Or any of a number of basic programming constructs? >> Ok, I guess you have while loops, using goto. >> Local variables. At least that are strings. Everything is a string. >> cmd has one or two surprisingly powerfuli features, such as for /f >> and set /a. If you can't do your work with them, you can't do it. >> sh is a bit more portable than Python, but not by much and >> imho at too large a cost in maintainability/generality. >> It still seems to me like a string based language that can't do much, >> but I admit I'm not practised in it. (I am very practised in .cmd.) >> >> >> You know, the fact that expression evaluation is in some mix of the "[" command >> and maybe in sh itself. That people write if xxx true else yyy instead >> of if not xxx yyy. >> The fact that Solaris is different. >> The fact that quoting is needed in various places. >> Quoting always bothers me. It is hard to predict how many levels >> of unquoting will be done. >> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >> but in fact they are escape characters, very wierd and bad. >> >> >> Cygwin and Interix both probably work fine. >> Someone just has to set them up and run them. >> >> >> Consider Cygwin and Interix almost the same. >> Interix is much faster, if you are calling fork a lot. >> Cygwin is slightly more compatible with Linux/Posix. >> >> >> Interix has a few ways in which is resembles Linux/Posix more though, >> such as not using extensions on executables, using ".so", supporting >> runpath. >> >> >> I think with Cygwin 1.7, both it and Interix go to extreme >> of supporting backward slash and colon in paths. >> Interix actually ors in 0xFF00 to such characters but >> it is transparent to Interix code. Or maybe that's what >> Cygwin does. I don't remember. It is completely non >> transparent and discoverable if you look at the results from Win32. >> >> >> Interix probably a larger download, because the >> part that is mostly "built in" is basically nothing, >> just some infrastructure and very few utilities. >> I don't think there is even sh or ksh. >> Everything else is one large download. >> >> >> On XP nothing is "builtin", there is just one large download. >> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >> >> >> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >> >> >> - Jay >> >> >> ---------------------------------------- [deliberate snip] CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 25 03:28:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:28:13 +0000 Subject: [M3devel] FW: Hudson question In-Reply-To: <4A6A1C90.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> <4A6A1C90.1E75.00D7.1@scires.com> Message-ID: > 1. CMD comes with Windows out-of-the-box. No extra config/install is required. So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate. > 2. I want to be able to launch a CMD window and use the cm3 command line tools > to build Modula-3 packages. > I also want to be able to run Modula-3 programs without need of > any other tools except what comes with Windows by default. Now the > latter isn't exactly possible if you are dependent on Agreed and not necessarily contradicted. You need CVS to get the current Modula-3 source, but not to use it. Where is the line? > the .NET framework, but most systems have .NET anyway because Microsoft > has pushed it out through online updates. How is the .NET framework relevant? > 3. I continue to experience problems with cygwin, python, etc. because the setup in > each is slightly different and there are dependencies that are not obvious. Let's work on this? What are the errors? I've installed them each many times on many computers with no problem. One problem you might hit is that you might have both Cygwin and native Python. Start out with just one or the other. > If you succeed in installing cm3 using cygwin, it isn't always possible to build/run > packages from CMD. Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH. However the use of sh is separate from the use of the NT386GNU platform. You can launch native NT386 cm3.exe from Cygwin sh. If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency. > I haven't been able to get the python scripts to work for me, despite installing python. Let's work on that? > 4. CM3IDE launches the native shell to run the cm3 command line tools. > On Windows, this shell is CMD. We need to preserve this functionality. There is no need for CM3IDE to launch any shell at all. Why does it? You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used. Just because a console app runs or a console window comes up, does not imply cmd is anywhere. You do need a cmd wrapper if you use, e.g. redirection, on the command line. Things like system() tend to use cmd. And the Modula-3 wrapper libraries might use cmd. But you really don't need any shell at all. I would not advocate any sh or Python wrapping. Adding sh really slow things down. Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection. > 5. I have provided various CMD scripts in the repository and I've been > keeping these up-to-date. I don't mind continuing to do this. And the Tinderbox and Hudson stuff? I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language. I also haven't (and might not) finished dupliating the .sh. I'm not sure. You know, "soon" I should try one or more of: Old Tinderbox/sh stuff on Windows. New Hudson/sh stuff on Windows. Either of above but having rewritten .sh in .cmd or py. Basically the story was, I was on vacation with a Mac. I needed/wanted changes to the .sh but was unwilling to work on .sh. It is cryptic and despite years of slightly trying, I can't seem to get the hang of it. And then I fear that anything I write will only work one OS. I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few. I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed. > 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. I commited working automation to build an .msi. It could use some polish though. The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3. I investigated a number of options for how to build the setup. I had never previously built an .msi, nor it follows, used Wix. I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner. I can detail what I remember of my experiences. IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files. Another .msi builder was and still is promising. NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience. I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running. > 7. Whatever automated test environment we provide on Windows must work in the > native shell in order to prove that stuff is working in that shell. If you use cygwin > or some other shell, that doesn't mean it will work in CMD. That is a fine line. Not necessarily true, but easier to prove true the other way around, granted. If you don't use Cygwin at all, then definitely the stuff works without Cygwin. If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it. But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script). Do the tests work outside Hudson? Outside Tinderbox? Well, it is not too difficult to run them outside either. Do they work outside the .cmd wrappers? Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake? Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening". Modula-3 is obviously general purpose. :) This dichotomy between "scripting" and non-scripting languages has long bugged me. The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate. I understand the guidance -- "pick the right tool for the job". But there is also guidance -- "don't have too many different tools; don't have a different tool for each job". If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving???? Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc... - Jay From jay.krell at cornell.edu Sat Jul 25 03:40:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:40:38 +0000 Subject: [M3devel] which new platforms do people want? Message-ID: Other than finishing ARM_DARWIN, what platforms are people interested in? And will actually use?? I have /many/ to choice from, via both virtual x86/AMD64 machines and available hardware. Some of these are started but didn't get as far yet as having archives uploaded. I386,AMD64_SOLARIS, NETBSD, OPENBSD (all started and mostly easy, will try to finish these up soon) Alpha of anything (VMS, Linux, *BSD, Tru64) AMD64_NT if MinGW is in good enough shape PPC_NETBSD (should be easy) PPC_FREEBSD (slightly hard to setup) Irix 32bit and 64bit AIX 32bit and 64bit HP-UX PA64 and IA64 (PA32 already in good shape) IA64 of anything (VMS, HP-UX, Linux, *BSD; Linux being the one I have up/running) MIPS of anything (Irix, Linux, *BSD (started)) ARM_LINUX PPC64_DARWIN, LINUX MSDOS/DJGPP (appears to have the timer support for user threads) PPC_MACOS, M68K_MACOS Plan9 (unlikely, uses old gcc fork, best handled with a C backend) Beos (unlikely, not very VM-compatible) DragonflyBSD (VM) WinCE (unlikely, no hardware) ? A C backend could serve pretty much anything. We could likely have C_WIN32 and C_POSIX and nearly all porting work declared done, just two distribution archives, if that. Of course then the "fun" of installing all these systems would be lost. :) I think I can knock off I386,AMD64_SOLARIS, NetBSD, OpenBSD, then try out more esoteric stuff like Alpha and MIPS and then IA64. My $50 network router runs Linux 2.4 on 32bit MIPS, I think with uclibc. It is low end for sure, but has SMB client builtin, so infinite diskspace. I have a network attached hard drive running Linux 2.6 on ARM, with uclibc. uclibc imho threatens our naming conventions, unless we target the Linux kernel instead of libc, which I think is maybe a good idea. Linux 2.4 also treatens the naming convention perhaps. I thought it was long gone but it isn't. Current "distributions" for network routers use it. Maybe there should be MIPS_LINUX_USERTHREADS? Maybe *_USERTHREADS in general, where it works and people will use it? - Jay From jay.krell at cornell.edu Sat Jul 25 03:42:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:42:04 +0000 Subject: [M3devel] FW: FW: Hudson question In-Reply-To: <4A6A1C90.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> <4A6A1C90.1E75.00D7.1@scires.com> Message-ID: [truncated again] ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Hudson question > Date: Sat, 25 Jul 2009 01:28:13 +0000 > > >> 1. CMD comes with Windows out-of-the-box. No extra config/install is required. > > > So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate. > > >> 2. I want to be able to launch a CMD window and use the cm3 command line tools >> to build Modula-3 packages. >> I also want to be able to run Modula-3 programs without need of >> any other tools except what comes with Windows by default. Now the >> latter isn't exactly possible if you are dependent on > > > Agreed and not necessarily contradicted. > You need CVS to get the current Modula-3 source, but not to use it. > Where is the line? > > >> the .NET framework, but most systems have .NET anyway because Microsoft >> has pushed it out through online updates. > > How is the .NET framework relevant? > > >> 3. I continue to experience problems with cygwin, python, etc. because the setup in >> each is slightly different and there are dependencies that are not obvious. > > > Let's work on this? What are the errors? I've installed them each many times on many computers with no problem. > One problem you might hit is that you might have both Cygwin and native Python. > Start out with just one or the other. > > >> If you succeed in installing cm3 using cygwin, it isn't always possible to build/run >> packages from CMD. > > > Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH. > > > However the use of sh is separate from the use of the NT386GNU platform. > You can launch native NT386 cm3.exe from Cygwin sh. > If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency. > > >> I haven't been able to get the python scripts to work for me, despite installing python. > > > Let's work on that? > > >> 4. CM3IDE launches the native shell to run the cm3 command line tools. >> On Windows, this shell is CMD. We need to preserve this functionality. > > There is no need for CM3IDE to launch any shell at all. > Why does it? > You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used. > Just because a console app runs or a console window comes up, does not imply cmd is anywhere. > You do need a cmd wrapper if you use, e.g. redirection, on the command line. > Things like system() tend to use cmd. > And the Modula-3 wrapper libraries might use cmd. > But you really don't need any shell at all. > > > I would not advocate any sh or Python wrapping. Adding sh really slow things down. > > > Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection. > > >> 5. I have provided various CMD scripts in the repository and I've been >> keeping these up-to-date. I don't mind continuing to do this. > > And the Tinderbox and Hudson stuff? > I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language. > I also haven't (and might not) finished dupliating the .sh. > I'm not sure. > You know, "soon" I should try one or more of: > Old Tinderbox/sh stuff on Windows. > New Hudson/sh stuff on Windows. > Either of above but having rewritten .sh in .cmd or py. > > > Basically the story was, I was on vacation with a Mac. > I needed/wanted changes to the .sh but was unwilling to work on .sh. > It is cryptic and despite years of slightly trying, I can't seem to get the hang of it. > And then I fear that anything I write will only work one OS. > I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few. > > I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed. > > >> 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. > > > I commited working automation to build an .msi. > It could use some polish though. > The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3. > > > I investigated a number of options for how to build the setup. > I had never previously built an .msi, nor it follows, used Wix. > I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner. > I can detail what I remember of my experiences. > IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files. > Another .msi builder was and still is promising. > NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience. > > > I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running. > > >> 7. Whatever automated test environment we provide on Windows must work in the >> native shell in order to prove that stuff is working in that shell. If you use cygwin >> or some other shell, that doesn't mean it will work in CMD. > > > That is a fine line. > Not necessarily true, but easier to prove true the other way around, granted. > If you don't use Cygwin at all, then definitely the stuff works without Cygwin. > If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it. > > But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script). > > Do the tests work outside Hudson? Outside Tinderbox? > Well, it is not too difficult to run them outside either. > Do they work outside the .cmd wrappers? > > Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake? > Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening". > > > Modula-3 is obviously general purpose. :) > > > This dichotomy between "scripting" and non-scripting languages has long bugged me. > The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate. > > I understand the guidance -- "pick the right tool for the job". > But there is also guidance -- "don't have too many different tools; don't have a different tool for each job". > > If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving???? > Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc... > > > - Jay > From jay.krell at cornell.edu Sat Jul 25 04:06:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 02:06:14 +0000 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: It seems the Tinderbox stuff always keeps around ~/work/cm3-ws/datetime, one for each run? I see them accumulating on my machines. Can you send me/all your exact cron entries? For Tinderbox and Hudson? Even what file they are in? And how cron is enabled in /etc? Just in case? Thanks. - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 11:44:38 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: Hudson errors out of diskspace > > Quoting Jay K : > >> Here's another: >> >> new source -> compiling ../FreeBSD4/cm3unix.c >> ../FreeBSD4/cm3unix.c:3: fatal error: error writing to >> /var/tmp/ccVwJXWF.s: No space left on device > > That was on my home machine because core dumps from m3tests were > accumulating in /var/tmp. I've now set the core dump limit to 0 > for those jobs. > >> Hudson is looking like a big improvement though -- the last success, >> last failure columns, the list of changes in a build, the quick >> access to the full output. > > Yes. I've been using it for about half a year now, and apart from the > fact that it's resource hungry and sometimes slow, it's easy to use > and configure. And you find a plug-in for almost everything. > > Since yesterday afternoon all necessary plug-ins for interaction > with other servers should be installed. > > I've just moved the crontab jobs from user m3 on birch to hudson, > see http://hudson.modula3.com:8080/view/m3-www-support/. > > My network connection is very unstable currently, so more failures > are to be expected. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Sat Jul 25 13:54:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 13:54:36 +0200 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: <20090725135436.4frp8e0c8w8ckgg4@mail.elegosoft.com> Quoting Jay K : > It seems the Tinderbox stuff always keeps around > ~/work/cm3-ws/datetime, one for each run? > I see them accumulating on my machines. Use cleanup_all from scripts/regression/defs.sh. > Can you send me/all your exact cron entries? > For Tinderbox and Hudson? Hudson doesn't have any crontab. It implements cron functionality itself. > Even what file they are in? I don't know where personal crontab files are kept (probably implementation dependent). You just use the crontab command to access them. > And how cron is enabled in /etc? Just in case? I don't think there is any system-independent way to enable cron. Just run the daemon from one of the system startup scripts (/etc/rc or /etc/rc.d/*). > Thanks. Here's the crontab of m3 on birch. Everything is disabled now (moved to Hudson). I'll add some remarks with -->. m3 at birch:~$ crontab -l MAILTO=m3-support at elego.de TESTHOSTNAME=birch.elegosoft.com ### Note: all these crontab jobs have been moved to the CM3 hudson instance on birch # m h dom mon dow command --> crontabs residing in /etc will likely have another field for the user: --> # m h dom mon dow user command #0 2,14 * * * cd ~/cm3 && BUILD_REL=lastok ./tinderbox-build.sh cm3.build >/dev/null #0 4,16 * * * cd ~/cm3 && ./tinderbox-build.sh cm3.build >/dev/null --> These were the release-build and last-ok build when LINUXLIBC6 was --> the target on birch #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_pkg_status.sh #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_m3tests.sh #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_snapshot_status.sh #*/30 * * * * ${HOME}/bin/update_changelog.sh #*/30 * * * * cd /var/www/modula3.elegosoft.com/cm3/uploaded-archives && ./update_download_index.sh #5 7 * * * cd /var/www/modula3.elegosoft.com/cm3/ && make all >/dev/null --> old WWW service entries before the crash # This should work ### 0 14 * * * cd ~/cm3 && BUILD_REL=lastok ./tinderbox-build.sh cm3.build >/dev/null 2>&1 --> This was run till yesterday, but with additional tests in cm3.build # Cannot work, no release archives for AMD64_LINUX #0 4,16 * * * cd ~/cm3 && ./tinderbox-build.sh cm3.build >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_pkg_status.sh >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_m3tests.sh >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_snapshot_status.sh >/dev/null 2>&1 ### */60 * * * * ${HOME}/bin/update_changelog.sh >/dev/null 2>&1 ### */30 * * * * cd /var/www/modula3.elegosoft.com/cm3/uploaded-archives && ./update_download_index.sh >/dev/null 2>&1 ### 5 7 * * * cd /var/www/modula3.elegosoft.com/cm3/ && make all >/dev/null >/dev/null 2>&1 --> entries inserted after the crash, when nothing was working correctly... Does that help? If you can run Hudson on any of your systems, I wouldn't bother with cron. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 16:58:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 09:58:24 -0500 Subject: [M3devel] Fwd: Output from "cron" command References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> Message-ID: <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> This is an old error for Solaris that I fixed a long time ago. Can someone restore? Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: July 25, 2009 5:30:35 AM CDT > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > U regression-scripts/defs.sh > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.07.25 06:30:23 -- checkout in progress. > [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is not > of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set > incorrectly, or the mail was delayed for a long time. > variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.07.25 06:30:32 -- checkout in progress. > [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is not > of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set > incorrectly, or the mail was delayed for a long time. > variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 20:00:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:00:26 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> Message-ID: <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> Quoting Tony Hosking : > This is an old error for Solaris that I fixed a long time ago. Can > someone restore? Hi Tony, as far as I can see nothing has changed regarding STARTTIME: > % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME|date' Annotations for scripts/regression/tinderbox-build.sh *************** 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date '+%Y%m%d-%H%M%S'`" 1.8 (wagner 03-Feb-08): STARTTIME="$4" 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z "${BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] 1.8 (wagner 03-Feb-08): echo " date 'date +%s'" 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date +%s` 1.8 (wagner 03-Feb-08): tinderbox_header "${TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." 1.10 (hosking 09-Mar-08): echo "[start checkout `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end checkout `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- compile in progress." 1.10 (hosking 09-Mar-08): echo "[start compile `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- tests in progress." 1.10 (hosking 09-Mar-08): echo "[start run-tests `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end run-tests `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." Nothing at all has changed in these scripts in July: % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 Annotations for scripts/regression/tinderbox-build.sh *************** luthien [~/work/cm3] wagner % cvs ann scripts/regression/cm3.bu | egrep Jul-09 cm3.build cm3.build~ luthien [~/work/cm3] wagner % cvs ann scripts/regression/cm3.build | egrep Jul-09 Annotations for scripts/regression/cm3.build *************** luthien [~/work/cm3] wagner Perhaps I'm looking for the wrong thing. What exactly did you change long ago to make it work? I'm at a loss now. > Sent from my iPhone You seem to be very `mobile' lately ;-) > Begin forwarded message: > >> From: Tony Hosking >> Date: July 25, 2009 5:30:35 AM CDT >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> > >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> U regression-scripts/defs.sh >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.07.25 06:30:23 -- checkout in progress. >> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is not >> of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set >> incorrectly, or the mail was delayed for a long time. >> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >> >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.07.25 06:30:32 -- checkout in progress. >> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is not >> of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set >> incorrectly, or the mail was delayed for a long time. >> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >> >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 25 20:10:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:10:52 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc Message-ID: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> We've got two failures for package tests on birch that don't show up on FreeBSD: http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ I think Jay already mentioned that there might be a conflict. Any objections to rename the m3 library? I think I'll just try it and see what happens... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 20:12:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 18:12:19 +0000 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: I thought I already renamed it but maybe I messed up or maybe the report is old? - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 20:10:52 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] package test failures on birch: duplicate libodbc > > We've got two failures for package tests on birch that don't show up > on FreeBSD: > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ > > I think Jay already mentioned that there might be a conflict. > > Any objections to rename the m3 library? > > I think I'll just try it and see what happens... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Sat Jul 25 20:16:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:16:55 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: <20090725201655.030d1ygif4cgksg4@mail.elegosoft.com> Quoting Jay K : > I thought I already renamed it but maybe I messed up or maybe the > report is old? I just found out you had, too. The report is not old. Perhaps we need to remove old libs manually which are still left in /usr/local/cm3/lib? I'll try that... Olaf > > - Jay > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:10:52 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] package test failures on birch: duplicate libodbc >> >> We've got two failures for package tests on birch that don't show up >> on FreeBSD: >> >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >> >> I think Jay already mentioned that there might be a conflict. >> >> Any objections to rename the m3 library? >> >> I think I'll just try it and see what happens... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 20:15:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 18:15:14 +0000 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: Hm, maybe the problem is that shipping should delete the old files? Should I add something called, like install_delete_file? delete_installed_file?? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 25 Jul 2009 18:12:19 +0000 > Subject: Re: [M3devel] package test failures on birch: duplicate libodbc > > > I thought I already renamed it but maybe I messed up or maybe the report is old? > > - Jay > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:10:52 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] package test failures on birch: duplicate libodbc >> >> We've got two failures for package tests on birch that don't show up >> on FreeBSD: >> >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >> >> I think Jay already mentioned that there might be a conflict. >> >> Any objections to rename the m3 library? >> >> I think I'll just try it and see what happens... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sat Jul 25 20:27:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:27:10 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: <20090725202710.xq62yw55c848o8g4@mail.elegosoft.com> Quoting Jay K : > Hm, maybe the problem is that shipping should delete the old files? > > Should I add something called, like install_delete_file? > delete_installed_file?? No, this is a migration problem that cannot be solved by the build tooling without being aware of all the history. I just removed all cm3 libodbc.so files on birch (except those in your home). If the tests succeed now, we can forget about it. Olaf > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Date: Sat, 25 Jul 2009 18:12:19 +0000 >> Subject: Re: [M3devel] package test failures on birch: duplicate libodbc >> >> >> I thought I already renamed it but maybe I messed up or maybe the >> report is old? >> >> - Jay >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:10:52 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] package test failures on birch: duplicate libodbc >>> >>> We've got two failures for package tests on birch that don't show up >>> on FreeBSD: >>> >>> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >>> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >>> >>> I think Jay already mentioned that there might be a conflict. >>> >>> Any objections to rename the m3 library? >>> >>> I think I'll just try it and see what happens... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 20:32:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 14:32:08 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> Message-ID: <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> Perhaps I am confusing with the original change I made for 1.10 to the parameter to the "date" command. In any case, something changed so that my scripts did not run properly. It's been a long time since I've seen a sane tinderbox run for Solaris -- will things be stabilising soon? -- Tony (not mobile) On 25 Jul 2009, at 14:00, Olaf Wagner wrote: > Quoting Tony Hosking : > >> This is an old error for Solaris that I fixed a long time ago. Can >> someone restore? > > Hi Tony, > > as far as I can see nothing has changed regarding STARTTIME: > > >> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| >> date' > > Annotations for scripts/regression/tinderbox-build.sh > *************** > 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date '+%Y > %m%d-%H%M%S'`" > 1.8 (wagner 03-Feb-08): STARTTIME="$4" > 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z "$ > {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] > 1.8 (wagner 03-Feb-08): echo > " date 'date +%s'" > 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: > $STARTTIME > 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + > %s` > 1.8 (wagner 03-Feb-08): tinderbox_header "$ > {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" > 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- checkout in progress." > 1.10 (hosking 09-Mar-08): echo "[start checkout `date '+ > %Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end checkout `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- compile in progress." > 1.10 (hosking 09-Mar-08): echo "[start compile `date '+ > %Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- tests in progress." > 1.10 (hosking 09-Mar-08): echo "[start run-tests `date > '+%Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end run-tests `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- checkout, compile and test run done." > > Nothing at all has changed in these scripts in July: > > % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 > > Annotations for scripts/regression/tinderbox-build.sh > *************** > luthien [~/work/cm3] wagner > % cvs ann scripts/regression/cm3.bu | egrep Jul-09 > cm3.build cm3.build~ > luthien [~/work/cm3] wagner > % cvs ann scripts/regression/cm3.build | egrep Jul-09 > > Annotations for scripts/regression/cm3.build > *************** > luthien [~/work/cm3] wagner > > > Perhaps I'm looking for the wrong thing. What exactly did you change > long ago to make it work? I'm at a loss now. > >> Sent from my iPhone > > You seem to be very `mobile' lately ;-) > > >> Begin forwarded message: >> >>> From: Tony Hosking >>> Date: July 25, 2009 5:30:35 AM CDT >>> To: hosking at cs.purdue.edu >>> Subject: Output from "cron" command >>> >> >>> Your "cron" job on niagara.cs.purdue.edu >>> $HOME/cm3/scripts/regression/cron.sh >>> >>> produced the following output: >>> >>> U regression-scripts/defs.sh >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>> >>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.07.25 06:30:23 -- checkout in progress. >>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>> is set incorrectly, or the mail was delayed for a long time. >>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>> >>> Error: Sending buildlog failed! >>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>> >>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.07.25 06:30:32 -- checkout in progress. >>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>> is set incorrectly, or the mail was delayed for a long time. >>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>> minutes) >>> >>> Error: Sending buildlog failed! >>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 20:44:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:44:38 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> Message-ID: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Quoting Tony Hosking : > Perhaps I am confusing with the original change I made for 1.10 to the > parameter to the "date" command. > > In any case, something changed so that my scripts did not run > properly. It's been a long time since I've seen a sane tinderbox run > for Solaris -- will things be stabilising soon? I broke the last one yesterday with $() (fixed soon afterwards), but the one before succeeded: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 I was hoping to get a green build from one of your systems today (big-endian, different architecture) to finally fix the RC2 tag. But if you cannot send your results to the tinderbox that will be difficult :-/ I really don't understand why that should have stopped working. The error below seems to be that the reported start time is 0, and that cannot be according to the source. Could you set -x at the start of the tinderbox script and try again? Jay, can you think of anything you have changed that may cause Tony's problem? Olaf > -- Tony (not mobile) :-) > On 25 Jul 2009, at 14:00, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> This is an old error for Solaris that I fixed a long time ago. Can >>> someone restore? >> >> Hi Tony, >> >> as far as I can see nothing has changed regarding STARTTIME: >> >> >>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >> >> Annotations for scripts/regression/tinderbox-build.sh >> *************** >> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >> '+%Y %m%d-%H%M%S'`" >> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >> 1.8 (wagner 03-Feb-08): echo " >> date 'date +%s'" >> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >> %S'` -- checkout in progress." >> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >> '+ %Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >> '+%Y. %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >> %H:%M: %S'` -- compile in progress." >> 1.10 (hosking 09-Mar-08): echo "[start compile `date >> '+ %Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >> %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >> %H:%M: %S'` -- tests in progress." >> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >> '+%Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >> '+%Y. %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >> %S'` -- checkout, compile and test run done." >> >> Nothing at all has changed in these scripts in July: >> >> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >> >> Annotations for scripts/regression/tinderbox-build.sh >> *************** >> luthien [~/work/cm3] wagner >> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >> cm3.build cm3.build~ >> luthien [~/work/cm3] wagner >> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >> >> Annotations for scripts/regression/cm3.build >> *************** >> luthien [~/work/cm3] wagner >> >> >> Perhaps I'm looking for the wrong thing. What exactly did you change >> long ago to make it work? I'm at a loss now. >> >>> Sent from my iPhone >> >> You seem to be very `mobile' lately ;-) >> >> >>> Begin forwarded message: >>> >>>> From: Tony Hosking >>>> Date: July 25, 2009 5:30:35 AM CDT >>>> To: hosking at cs.purdue.edu >>>> Subject: Output from "cron" command >>>> >>> >>>> Your "cron" job on niagara.cs.purdue.edu >>>> $HOME/cm3/scripts/regression/cron.sh >>>> >>>> produced the following output: >>>> >>>> U regression-scripts/defs.sh >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>> >>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.07.25 06:30:23 -- checkout in progress. >>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>> is set incorrectly, or the mail was delayed for a long time. >>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>> >>>> Error: Sending buildlog failed! >>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>> >>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.07.25 06:30:32 -- checkout in progress. >>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>> is set incorrectly, or the mail was delayed for a long time. >>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>> >>>> Error: Sending buildlog failed! >>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 21:19:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:19:11 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: This line: echo tinderbox: timenow: `date +%s` needs to more like these lines: echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' 2009.07.25 12:13:54 -bash-3.00$ date '+%m.%d.%y %H:%M:%S' 07.25.09 12:14:33 -bash-3.00$ date +%s %s - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 20:44:38 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Quoting Tony Hosking : > >> Perhaps I am confusing with the original change I made for 1.10 to the >> parameter to the "date" command. >> >> In any case, something changed so that my scripts did not run >> properly. It's been a long time since I've seen a sane tinderbox run >> for Solaris -- will things be stabilising soon? > > I broke the last one yesterday with $() (fixed soon afterwards), but > the one before succeeded: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 > > I was hoping to get a green build from one of your systems today > (big-endian, different architecture) to finally fix the RC2 tag. > But if you cannot send your results to the tinderbox that will be > difficult :-/ I really don't understand why that should have stopped > working. > > The error below seems to be that the reported start time is 0, and > that cannot be according to the source. Could you set -x at the start > of the tinderbox script and try again? > > Jay, can you think of anything you have changed that may cause Tony's > problem? > > Olaf > >> -- Tony (not mobile) > :-) > >> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> This is an old error for Solaris that I fixed a long time ago. Can >>>> someone restore? >>> >>> Hi Tony, >>> >>> as far as I can see nothing has changed regarding STARTTIME: >>> >>> >>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>> >>> Annotations for scripts/regression/tinderbox-build.sh >>> *************** >>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>> '+%Y %m%d-%H%M%S'`" >>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>> 1.8 (wagner 03-Feb-08): echo " >>> date 'date +%s'" >>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>> %S'` -- checkout in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>> '+ %Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>> '+%Y. %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>> %H:%M: %S'` -- compile in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>> '+ %Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>> %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>> %H:%M: %S'` -- tests in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>> '+%Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>> '+%Y. %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>> %S'` -- checkout, compile and test run done." >>> >>> Nothing at all has changed in these scripts in July: >>> >>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>> >>> Annotations for scripts/regression/tinderbox-build.sh >>> *************** >>> luthien [~/work/cm3] wagner >>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>> cm3.build cm3.build~ >>> luthien [~/work/cm3] wagner >>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>> >>> Annotations for scripts/regression/cm3.build >>> *************** >>> luthien [~/work/cm3] wagner >>> >>> >>> Perhaps I'm looking for the wrong thing. What exactly did you change >>> long ago to make it work? I'm at a loss now. >>> >>>> Sent from my iPhone >>> >>> You seem to be very `mobile' lately ;-) >>> >>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> U regression-scripts/defs.sh >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>> is set incorrectly, or the mail was delayed for a long time. >>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>> >>>>> Error: Sending buildlog failed! >>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>> is set incorrectly, or the mail was delayed for a long time. >>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>> >>>>> Error: Sending buildlog failed! >>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sat Jul 25 21:19:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:19:57 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: (two occurences of that) ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Fwd: Output from "cron" command > Date: Sat, 25 Jul 2009 19:19:11 +0000 > > > This line: > > > echo tinderbox: timenow: `date +%s` > > needs to more like these lines: > > echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." > > echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." > > > -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' > 2009.07.25 12:13:54 > > -bash-3.00$ date '+%m.%d.%y %H:%M:%S' > 07.25.09 12:14:33 > > -bash-3.00$ date +%s > %s > > - Jay > > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:44:38 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Quoting Tony Hosking : >> >>> Perhaps I am confusing with the original change I made for 1.10 to the >>> parameter to the "date" command. >>> >>> In any case, something changed so that my scripts did not run >>> properly. It's been a long time since I've seen a sane tinderbox run >>> for Solaris -- will things be stabilising soon? >> >> I broke the last one yesterday with $() (fixed soon afterwards), but >> the one before succeeded: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >> >> I was hoping to get a green build from one of your systems today >> (big-endian, different architecture) to finally fix the RC2 tag. >> But if you cannot send your results to the tinderbox that will be >> difficult :-/ I really don't understand why that should have stopped >> working. >> >> The error below seems to be that the reported start time is 0, and >> that cannot be according to the source. Could you set -x at the start >> of the tinderbox script and try again? >> >> Jay, can you think of anything you have changed that may cause Tony's >> problem? >> >> Olaf >> >>> -- Tony (not mobile) >> :-) >> >>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>> >>>> Quoting Tony Hosking : >>>> >>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>> someone restore? >>>> >>>> Hi Tony, >>>> >>>> as far as I can see nothing has changed regarding STARTTIME: >>>> >>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>>> >>>> Annotations for scripts/regression/tinderbox-build.sh >>>> *************** >>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>> '+%Y %m%d-%H%M%S'`" >>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>> 1.8 (wagner 03-Feb-08): echo " >>>> date 'date +%s'" >>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>> %S'` -- checkout in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>> '+%Y. %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>> %H:%M: %S'` -- compile in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>> %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>> %H:%M: %S'` -- tests in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>> '+%Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>> '+%Y. %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>> %S'` -- checkout, compile and test run done." >>>> >>>> Nothing at all has changed in these scripts in July: >>>> >>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>> >>>> Annotations for scripts/regression/tinderbox-build.sh >>>> *************** >>>> luthien [~/work/cm3] wagner >>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>> cm3.build cm3.build~ >>>> luthien [~/work/cm3] wagner >>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>> >>>> Annotations for scripts/regression/cm3.build >>>> *************** >>>> luthien [~/work/cm3] wagner >>>> >>>> >>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>> long ago to make it work? I'm at a loss now. >>>> >>>>> Sent from my iPhone >>>> >>>> You seem to be very `mobile' lately ;-) >>>> >>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Tony Hosking >>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>> To: hosking at cs.purdue.edu >>>>>> Subject: Output from "cron" command >>>>>> >>>>> >>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>> >>>>>> produced the following output: >>>>>> >>>>>> U regression-scripts/defs.sh >>>>>> TESTHOSTNAME=niagara >>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>> LASTREL=5.4.0 >>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>> CM3_OSTYPE=POSIX >>>>>> CM3_TARGET=SOLgnu >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSUSER= >>>>>> testing ssh birch.elegosoft.com.. >>>>>> ssh birch.elegosoft.com ok >>>>>> Building cm3. >>>>>> Tinderbox Tree: "cm3" >>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>> >>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>> >>>>>> --- >>>>>> >>>>>> checkout, compile and test of cm3 ... >>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>> >>>>>> Error: Sending buildlog failed! >>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>> cleaning CM3 workspaces... >>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>> >>>>>> cleaning regression test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>> >>>>>> cleaning m3test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>> >>>>>> cleaning snapshot files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>> >>>>>> cleaning package reports... >>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>> >>>>>> TESTHOSTNAME=niagara >>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>> LASTREL=5.4.0 >>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>> CM3_OSTYPE=POSIX >>>>>> CM3_TARGET=SOLgnu >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSUSER= >>>>>> testing ssh birch.elegosoft.com.. >>>>>> ssh birch.elegosoft.com ok >>>>>> Building cm3. >>>>>> Tinderbox Tree: "cm3" >>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>> >>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>> >>>>>> --- >>>>>> >>>>>> checkout, compile and test of cm3 ... >>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>> >>>>>> Error: Sending buildlog failed! >>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>> cleaning CM3 workspaces... >>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>> >>>>>> cleaning regression test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>> >>>>>> cleaning m3test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>> >>>>>> cleaning snapshot files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>> >>>>>> cleaning package reports... >>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sat Jul 25 21:26:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:26:37 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: Can I suggest the portable scripting language C? -bash-3.00$ cat date.c #include #include #include int main() { printf("%lu\n", (unsigned long)time(NULL)); return 0; } -bash-3.00$ cc date.c -o ./mydate -bash-3.00$ ./mydate 1248549753 -bash-3.00$ pwd /dev2/cm3/scripts use that instead? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > Date: Sat, 25 Jul 2009 19:19:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > > (two occurences of that) > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sat, 25 Jul 2009 19:19:11 +0000 >> >> >> This line: >> >> >> echo tinderbox: timenow: `date +%s` >> >> needs to more like these lines: >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." >> >> >> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >> 2009.07.25 12:13:54 >> >> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >> 07.25.09 12:14:33 >> >> -bash-3.00$ date +%s >> %s >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>> parameter to the "date" command. >>>> >>>> In any case, something changed so that my scripts did not run >>>> properly. It's been a long time since I've seen a sane tinderbox run >>>> for Solaris -- will things be stabilising soon? >>> >>> I broke the last one yesterday with $() (fixed soon afterwards), but >>> the one before succeeded: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>> >>> I was hoping to get a green build from one of your systems today >>> (big-endian, different architecture) to finally fix the RC2 tag. >>> But if you cannot send your results to the tinderbox that will be >>> difficult :-/ I really don't understand why that should have stopped >>> working. >>> >>> The error below seems to be that the reported start time is 0, and >>> that cannot be according to the source. Could you set -x at the start >>> of the tinderbox script and try again? >>> >>> Jay, can you think of anything you have changed that may cause Tony's >>> problem? >>> >>> Olaf >>> >>>> -- Tony (not mobile) >>> :-) >>> >>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>> someone restore? >>>>> >>>>> Hi Tony, >>>>> >>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>> >>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>> '+%Y %m%d-%H%M%S'`" >>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>> 1.8 (wagner 03-Feb-08): echo " >>>>> date 'date +%s'" >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- compile in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>> %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- tests in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout, compile and test run done." >>>>> >>>>> Nothing at all has changed in these scripts in July: >>>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>> cm3.build cm3.build~ >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/cm3.build >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> >>>>> >>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>> long ago to make it work? I'm at a loss now. >>>>> >>>>>> Sent from my iPhone >>>>> >>>>> You seem to be very `mobile' lately ;-) >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Tony Hosking >>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Subject: Output from "cron" command >>>>>>> >>>>>> >>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>> >>>>>>> produced the following output: >>>>>>> >>>>>>> U regression-scripts/defs.sh >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From wagner at elegosoft.com Sat Jul 25 21:52:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 21:52:13 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> I don't see how that will help us... It worked for Tony for over a year, and nothing obvious has changed. Or did something change on your side, Tony (system upgrade, path setting, ...)? It's not good to introduce arbitrary changes now without understanding why it breaks. Olaf Quoting Jay K : > > Can I suggest the portable scripting language C? > > > -bash-3.00$ cat date.c > #include > #include > #include > int main() > { > printf("%lu\n", (unsigned long)time(NULL)); > return 0; > } > -bash-3.00$ cc date.c -o ./mydate > -bash-3.00$ ./mydate > 1248549753 > -bash-3.00$ pwd > /dev2/cm3/scripts > > > use that instead? > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> Date: Sat, 25 Jul 2009 19:19:57 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> >> (two occurences of that) >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>> >>> >>> This line: >>> >>> >>> echo tinderbox: timenow: `date +%s` >>> >>> needs to more like these lines: >>> >>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>> >>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." >>> >>> >>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>> 2009.07.25 12:13:54 >>> >>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>> 07.25.09 12:14:33 >>> >>> -bash-3.00$ date +%s >>> %s >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>> From: wagner at elegosoft.com >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> Quoting Tony Hosking : >>>> >>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>> parameter to the "date" command. >>>>> >>>>> In any case, something changed so that my scripts did not run >>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>> for Solaris -- will things be stabilising soon? >>>> >>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>> the one before succeeded: >>>> >>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>> >>>> I was hoping to get a green build from one of your systems today >>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>> But if you cannot send your results to the tinderbox that will be >>>> difficult :-/ I really don't understand why that should have stopped >>>> working. >>>> >>>> The error below seems to be that the reported start time is 0, and >>>> that cannot be according to the source. Could you set -x at the start >>>> of the tinderbox script and try again? >>>> >>>> Jay, can you think of anything you have changed that may cause Tony's >>>> problem? >>>> >>>> Olaf >>>> >>>>> -- Tony (not mobile) >>>> :-) >>>> >>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>> >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>> someone restore? >>>>>> >>>>>> Hi Tony, >>>>>> >>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>> >>>>>> >>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>> 'STARTTIME| date' >>>>>> >>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>> *************** >>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>> '+%Y %m%d-%H%M%S'`" >>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>> date 'date +%s'" >>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>> %S'` -- checkout in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>> %H:%M: %S'` -- compile in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>> %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>> %H:%M: %S'` -- tests in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>> %S'` -- checkout, compile and test run done." >>>>>> >>>>>> Nothing at all has changed in these scripts in July: >>>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>> >>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>> *************** >>>>>> luthien [~/work/cm3] wagner >>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>> cm3.build cm3.build~ >>>>>> luthien [~/work/cm3] wagner >>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>> >>>>>> Annotations for scripts/regression/cm3.build >>>>>> *************** >>>>>> luthien [~/work/cm3] wagner >>>>>> >>>>>> >>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>> long ago to make it work? I'm at a loss now. >>>>>> >>>>>>> Sent from my iPhone >>>>>> >>>>>> You seem to be very `mobile' lately ;-) >>>>>> >>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: Tony Hosking >>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Subject: Output from "cron" command >>>>>>>> >>>>>>> >>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>> >>>>>>>> produced the following output: >>>>>>>> >>>>>>>> U regression-scripts/defs.sh >>>>>>>> TESTHOSTNAME=niagara >>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>> LASTREL=5.4.0 >>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>> CM3_OSTYPE=POSIX >>>>>>>> CM3_TARGET=SOLgnu >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSUSER= >>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>> ssh birch.elegosoft.com ok >>>>>>>> Building cm3. >>>>>>>> Tinderbox Tree: "cm3" >>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>> >>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> checkout, compile and test of cm3 ... >>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>> >>>>>>>> Error: Sending buildlog failed! >>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>> cleaning CM3 workspaces... >>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>> >>>>>>>> cleaning regression test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>> >>>>>>>> cleaning m3test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>> >>>>>>>> cleaning snapshot files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>> >>>>>>>> cleaning package reports... >>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>> >>>>>>>> TESTHOSTNAME=niagara >>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>> LASTREL=5.4.0 >>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>> CM3_OSTYPE=POSIX >>>>>>>> CM3_TARGET=SOLgnu >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSUSER= >>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>> ssh birch.elegosoft.com ok >>>>>>>> Building cm3. >>>>>>>> Tinderbox Tree: "cm3" >>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>> >>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> checkout, compile and test of cm3 ... >>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>>>> >>>>>>>> Error: Sending buildlog failed! >>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>> cleaning CM3 workspaces... >>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>> >>>>>>>> cleaning regression test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>> >>>>>>>> cleaning m3test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>> >>>>>>>> cleaning snapshot files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>> >>>>>>>> cleaning package reports... >>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 21:54:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 15:54:49 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: Hmm. This is weird. I already have my own version of date (which accepts +%s) installed in my path so it should just work. My cron jobs sets the path accordingly: #/bin/sh CVS_RSH=ssh PATH=$HOME/bin:/opt/csw/bin:/opt/csw/gcc3/bin:/usr/ccs/bin:$PATH export CVS_RSH export PATH cd $HOME/cm3/scripts/regression ./tinderbox-build.sh cm3.build BUILD_REL=lastok ./tinderbox-build.sh cm3.build so I don't know where this new error is coming from (as Olaf points out tinderbox-build.sh hasn't changed significantly in any way that would trigger an error). Is there some other script not getting my private version $HOME/bin/date? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 25 Jul 2009, at 15:19, Jay K wrote: > > (two occurences of that) > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sat, 25 Jul 2009 19:19:11 +0000 >> >> >> This line: >> >> >> echo tinderbox: timenow: `date +%s` >> >> needs to more like these lines: >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run >> done." >> >> >> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >> 2009.07.25 12:13:54 >> >> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >> 07.25.09 12:14:33 >> >> -bash-3.00$ date +%s >> %s >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> Perhaps I am confusing with the original change I made for 1.10 >>>> to the >>>> parameter to the "date" command. >>>> >>>> In any case, something changed so that my scripts did not run >>>> properly. It's been a long time since I've seen a sane tinderbox >>>> run >>>> for Solaris -- will things be stabilising soon? >>> >>> I broke the last one yesterday with $() (fixed soon afterwards), but >>> the one before succeeded: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>> >>> I was hoping to get a green build from one of your systems today >>> (big-endian, different architecture) to finally fix the RC2 tag. >>> But if you cannot send your results to the tinderbox that will be >>> difficult :-/ I really don't understand why that should have stopped >>> working. >>> >>> The error below seems to be that the reported start time is 0, and >>> that cannot be according to the source. Could you set -x at the >>> start >>> of the tinderbox script and try again? >>> >>> Jay, can you think of anything you have changed that may cause >>> Tony's >>> problem? >>> >>> Olaf >>> >>>> -- Tony (not mobile) >>> :-) >>> >>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> This is an old error for Solaris that I fixed a long time ago. >>>>>> Can >>>>>> someone restore? >>>>> >>>>> Hi Tony, >>>>> >>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>> >>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>> 'STARTTIME| date' >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>> '+%Y %m%d-%H%M%S'`" >>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>> 1.8 (wagner 03-Feb-08): echo " >>>>> date 'date +%s'" >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- compile in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>> %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- tests in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout, compile and test run done." >>>>> >>>>> Nothing at all has changed in these scripts in July: >>>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>> cm3.build cm3.build~ >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/cm3.build >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> >>>>> >>>>> Perhaps I'm looking for the wrong thing. What exactly did you >>>>> change >>>>> long ago to make it work? I'm at a loss now. >>>>> >>>>>> Sent from my iPhone >>>>> >>>>> You seem to be very `mobile' lately ;-) >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Tony Hosking >>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Subject: Output from "cron" command >>>>>>> >>>>>> >>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>> >>>>>>> produced the following output: >>>>>>> >>>>>>> U regression-scripts/defs.sh >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>>>>>> minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 25 21:55:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 15:55:07 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> Message-ID: I've not changed anything on my side. On 25 Jul 2009, at 15:52, Olaf Wagner wrote: > I don't see how that will help us... It worked for Tony for over > a year, and nothing obvious has changed. Or did something change on > your side, Tony (system upgrade, path setting, ...)? > > It's not good to introduce arbitrary changes now without understanding > why it breaks. > > Olaf > > Quoting Jay K : > >> >> Can I suggest the portable scripting language C? >> >> >> -bash-3.00$ cat date.c >> #include >> #include >> #include >> int main() >> { >> printf("%lu\n", (unsigned long)time(NULL)); >> return 0; >> } >> -bash-3.00$ cc date.c -o ./mydate >> -bash-3.00$ ./mydate >> 1248549753 >> -bash-3.00$ pwd >> /dev2/cm3/scripts >> >> >> use that instead? >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> >>> (two occurences of that) >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>> >>>> >>>> This line: >>>> >>>> >>>> echo tinderbox: timenow: `date +%s` >>>> >>>> needs to more like these lines: >>>> >>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>> >>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>> run done." >>>> >>>> >>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>> 2009.07.25 12:13:54 >>>> >>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>> 07.25.09 12:14:33 >>>> >>>> -bash-3.00$ date +%s >>>> %s >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> Perhaps I am confusing with the original change I made for 1.10 >>>>>> to the >>>>>> parameter to the "date" command. >>>>>> >>>>>> In any case, something changed so that my scripts did not run >>>>>> properly. It's been a long time since I've seen a sane >>>>>> tinderbox run >>>>>> for Solaris -- will things be stabilising soon? >>>>> >>>>> I broke the last one yesterday with $() (fixed soon afterwards), >>>>> but >>>>> the one before succeeded: >>>>> >>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>> >>>>> I was hoping to get a green build from one of your systems today >>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>> But if you cannot send your results to the tinderbox that will be >>>>> difficult :-/ I really don't understand why that should have >>>>> stopped >>>>> working. >>>>> >>>>> The error below seems to be that the reported start time is 0, and >>>>> that cannot be according to the source. Could you set -x at the >>>>> start >>>>> of the tinderbox script and try again? >>>>> >>>>> Jay, can you think of anything you have changed that may cause >>>>> Tony's >>>>> problem? >>>>> >>>>> Olaf >>>>> >>>>>> -- Tony (not mobile) >>>>> :-) >>>>> >>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>> >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>> ago. Can >>>>>>>> someone restore? >>>>>>> >>>>>>> Hi Tony, >>>>>>> >>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>> >>>>>>> >>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>> 'STARTTIME| date' >>>>>>> >>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>> *************** >>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>> date 'date +%s'" >>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>> %S'` -- checkout in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>> %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>> %S'` -- checkout, compile and test run done." >>>>>>> >>>>>>> Nothing at all has changed in these scripts in July: >>>>>>> >>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>> >>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>> *************** >>>>>>> luthien [~/work/cm3] wagner >>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>> cm3.build cm3.build~ >>>>>>> luthien [~/work/cm3] wagner >>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>> >>>>>>> Annotations for scripts/regression/cm3.build >>>>>>> *************** >>>>>>> luthien [~/work/cm3] wagner >>>>>>> >>>>>>> >>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you >>>>>>> change >>>>>>> long ago to make it work? I'm at a loss now. >>>>>>> >>>>>>>> Sent from my iPhone >>>>>>> >>>>>>> You seem to be very `mobile' lately ;-) >>>>>>> >>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> From: Tony Hosking >>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Subject: Output from "cron" command >>>>>>>>> >>>>>>>> >>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>> >>>>>>>>> produced the following output: >>>>>>>>> >>>>>>>>> U regression-scripts/defs.sh >>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>> LASTREL=5.4.0 >>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSUSER= >>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>> Building cm3. >>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>> >>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>> log.txt >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>> minutes) >>>>>>>>> >>>>>>>>> Error: Sending buildlog failed! >>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>> cleaning CM3 workspaces... >>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>> >>>>>>>>> cleaning regression test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>> >>>>>>>>> cleaning m3test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>> >>>>>>>>> cleaning snapshot files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>> >>>>>>>>> cleaning package reports... >>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>> >>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>> LASTREL=5.4.0 >>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSUSER= >>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>> Building cm3. >>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>> >>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>> log.txt >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>>>>>>>> minutes) >>>>>>>>> >>>>>>>>> Error: Sending buildlog failed! >>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>> cleaning CM3 workspaces... >>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>> >>>>>>>>> cleaning regression test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>> >>>>>>>>> cleaning m3test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>> >>>>>>>>> cleaning snapshot files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>> >>>>>>>>> cleaning package reports... >>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>> >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>> Sitz: Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>> 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>> IdNr: DE163214194 >>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 22:00:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 22:00:15 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> Message-ID: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Quoting Tony Hosking : > I've not changed anything on my side. I don't understand why I missed that: revision 1.13 date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; let's just try plain date, based on the choices in the error message ---------------------------- But you seem to have fixed it already: revision 1.14 date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: yRpWy2mygKpT88Xt; Revert to what used to work. Strange that it didn't show up in my first diff. Olaf > > On 25 Jul 2009, at 15:52, Olaf Wagner wrote: > >> I don't see how that will help us... It worked for Tony for over >> a year, and nothing obvious has changed. Or did something change on >> your side, Tony (system upgrade, path setting, ...)? >> >> It's not good to introduce arbitrary changes now without understanding >> why it breaks. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Can I suggest the portable scripting language C? >>> >>> >>> -bash-3.00$ cat date.c >>> #include >>> #include >>> #include >>> int main() >>> { >>> printf("%lu\n", (unsigned long)time(NULL)); >>> return 0; >>> } >>> -bash-3.00$ cc date.c -o ./mydate >>> -bash-3.00$ ./mydate >>> 1248549753 >>> -bash-3.00$ pwd >>> /dev2/cm3/scripts >>> >>> >>> use that instead? >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> >>>> (two occurences of that) >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>> >>>>> >>>>> This line: >>>>> >>>>> >>>>> echo tinderbox: timenow: `date +%s` >>>>> >>>>> needs to more like these lines: >>>>> >>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>> >>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>> run done." >>>>> >>>>> >>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>> 2009.07.25 12:13:54 >>>>> >>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>> 07.25.09 12:14:33 >>>>> >>>>> -bash-3.00$ date +%s >>>>> %s >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>> >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>> parameter to the "date" command. >>>>>>> >>>>>>> In any case, something changed so that my scripts did not run >>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>> for Solaris -- will things be stabilising soon? >>>>>> >>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>> the one before succeeded: >>>>>> >>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>> >>>>>> I was hoping to get a green build from one of your systems today >>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>> But if you cannot send your results to the tinderbox that will be >>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>> working. >>>>>> >>>>>> The error below seems to be that the reported start time is 0, and >>>>>> that cannot be according to the source. Could you set -x at the start >>>>>> of the tinderbox script and try again? >>>>>> >>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>> problem? >>>>>> >>>>>> Olaf >>>>>> >>>>>>> -- Tony (not mobile) >>>>>> :-) >>>>>> >>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>> >>>>>>>> Quoting Tony Hosking : >>>>>>>> >>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>> someone restore? >>>>>>>> >>>>>>>> Hi Tony, >>>>>>>> >>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>> >>>>>>>> >>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>> 'STARTTIME| date' >>>>>>>> >>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>> *************** >>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>> date 'date +%s'" >>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>> %S'` -- checkout in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>> >>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>> >>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>> >>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>> *************** >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>> cm3.build cm3.build~ >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>> >>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>> *************** >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> >>>>>>>> >>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>> >>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>>> From: Tony Hosking >>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>> >>>>>>>>>> produced the following output: >>>>>>>>>> >>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSUSER= >>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>> Building cm3. >>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>> >>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>> >>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>> >>>>>>>>>> cleaning regression test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>> >>>>>>>>>> cleaning m3test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>> >>>>>>>>>> cleaning snapshot files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>> >>>>>>>>>> cleaning package reports... >>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>> >>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSUSER= >>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>> Building cm3. >>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>> >>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>> >>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>> >>>>>>>>>> cleaning regression test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>> >>>>>>>>>> cleaning m3test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>> >>>>>>>>>> cleaning snapshot files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>> >>>>>>>>>> cleaning package reports... >>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>> >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>> 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>> Sitz: Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>> DE163214194 >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>> 23 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>> IdNr: DE163214194 >>>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 05:09:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 03:09:59 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: Tony reverted it. I'm bringing my Solaris/sparc machine up to date and will try running Tinderbox. I will likely try with plain date and see what happens there and otherwise. - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 22:00:15 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Quoting Tony Hosking : > >> I've not changed anything on my side. > > I don't understand why I missed that: > > revision 1.13 > date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; > let's just try plain date, based on the choices in the error message > ---------------------------- > > But you seem to have fixed it already: > > revision 1.14 > date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: yRpWy2mygKpT88Xt; > Revert to what used to work. > > Strange that it didn't show up in my first diff. > > Olaf > > >> >> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >> >>> I don't see how that will help us... It worked for Tony for over >>> a year, and nothing obvious has changed. Or did something change on >>> your side, Tony (system upgrade, path setting, ...)? >>> >>> It's not good to introduce arbitrary changes now without understanding >>> why it breaks. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Can I suggest the portable scripting language C? >>>> >>>> >>>> -bash-3.00$ cat date.c >>>> #include >>>> #include >>>> #include >>>> int main() >>>> { >>>> printf("%lu\n", (unsigned long)time(NULL)); >>>> return 0; >>>> } >>>> -bash-3.00$ cc date.c -o ./mydate >>>> -bash-3.00$ ./mydate >>>> 1248549753 >>>> -bash-3.00$ pwd >>>> /dev2/cm3/scripts >>>> >>>> >>>> use that instead? >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>> >>>>> >>>>> (two occurences of that) >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>> >>>>>> >>>>>> This line: >>>>>> >>>>>> >>>>>> echo tinderbox: timenow: `date +%s` >>>>>> >>>>>> needs to more like these lines: >>>>>> >>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>> >>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>> run done." >>>>>> >>>>>> >>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>> 2009.07.25 12:13:54 >>>>>> >>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>> 07.25.09 12:14:33 >>>>>> >>>>>> -bash-3.00$ date +%s >>>>>> %s >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>> From: wagner at elegosoft.com >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>> >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>>> parameter to the "date" command. >>>>>>>> >>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>> >>>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>>> the one before succeeded: >>>>>>> >>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>> >>>>>>> I was hoping to get a green build from one of your systems today >>>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>>> But if you cannot send your results to the tinderbox that will be >>>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>>> working. >>>>>>> >>>>>>> The error below seems to be that the reported start time is 0, and >>>>>>> that cannot be according to the source. Could you set -x at the start >>>>>>> of the tinderbox script and try again? >>>>>>> >>>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>>> problem? >>>>>>> >>>>>>> Olaf >>>>>>> >>>>>>>> -- Tony (not mobile) >>>>>>> :-) >>>>>>> >>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Quoting Tony Hosking : >>>>>>>>> >>>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>>> someone restore? >>>>>>>>> >>>>>>>>> Hi Tony, >>>>>>>>> >>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>> >>>>>>>>> >>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>> 'STARTTIME| date' >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>> *************** >>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>> date 'date +%s'" >>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>> %S'` -- checkout in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>> >>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>> >>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>> *************** >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>> cm3.build cm3.build~ >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>> *************** >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>> >>>>>>>>> >>>>>>>>>> Begin forwarded message: >>>>>>>>>> >>>>>>>>>>> From: Tony Hosking >>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>> >>>>>>>>>>> produced the following output: >>>>>>>>>>> >>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>> Building cm3. >>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>> >>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>>> >>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>> >>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>> >>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>> >>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>> >>>>>>>>>>> cleaning package reports... >>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>> >>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>> Building cm3. >>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>> >>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>> >>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>> >>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>> >>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>> >>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>> >>>>>>>>>>> cleaning package reports... >>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>> Sitz: Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>> DE163214194 >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>> IdNr: DE163214194 >>>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 26 06:23:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 04:23:40 +0000 Subject: [M3devel] "32" in target names? Message-ID: "32" in target names? I introduced: PPC32_OPENBSD PA32_HPUX SPARC32_LINUX Should these be renamed? PPC_OPENBSD SPARC_LINUX PA_HPUX? HPPA_HPUX? In the case of the last two, 64bit targets are a pretty clear possibility -- SPARC64_LINUX, PA64_HPUX?HPPA64_HPUX Less so for PPC64 -- Linux, Darwin, AIX, sure, but PPC64_*BSD doesn't seem to be happening. - Jay From jay.krell at cornell.edu Sun Jul 26 09:25:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 07:25:04 +0000 Subject: [M3devel] Tinderbox/Hudson Message-ID: - The links to my Tinderbox test results don't work. - Why are my Tinderbox status usually yellow even though the logs look ok? Due the missing test results? - I do already have Hudson server running OpenBSD/x86, that was easy, not configured yet (still cross building cm3 and will try a Tinderbox run first instead.) LINUXLIBC6 is yellow, but this looks ok: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 Do they have to be more recent? Or need last release and last ok? I only do last ok. You don't have last release for AMD64_LINUX, it doesn't exist, but are green. Maybe two separate builds are needed? SPARC32_LINUX is yellow but it also looks ok. http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 The most recent completed PPC_LINUX failed to get much of the source tree in the CVS checkout. That happens often. I should probably put in a retry or something.. (Bringing back I386_DARWIN, funny thing there, is that to compile X client, you need Python, and the in-box one isn't new enough, and current doesn't build out of the box because it assumes a full Mac system..still working on it..) - Jay From wagner at elegosoft.com Sun Jul 26 11:10:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 11:10:41 +0200 Subject: [M3devel] "32" in target names? In-Reply-To: References: Message-ID: <20090726111041.dx7sjj2hw44g0gck@mail.elegosoft.com> Quoting Jay K : > "32" in target names? > > I introduced: > PPC32_OPENBSD > PA32_HPUX > SPARC32_LINUX > > > Should these be renamed? > PPC_OPENBSD > SPARC_LINUX > PA_HPUX? HPPA_HPUX? > In the case of the last two, 64bit targets are a pretty clear > possibility -- SPARC64_LINUX, PA64_HPUX?HPPA64_HPUX > Less so for PPC64 -- Linux, Darwin, AIX, sure, but PPC64_*BSD > doesn't seem to be happening. I vote for keeping a clear distinction, so keep the 32. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Jul 26 11:17:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 11:17:49 +0200 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: References: Message-ID: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Quoting Jay K : > - The links to my Tinderbox test results don't work. > > - Why are my Tinderbox status usually yellow even though the logs look ok? > Due the missing test results? > > - I do already have Hudson server running OpenBSD/x86, that was > easy, not configured yet (still cross building cm3 and will try a > Tinderbox run first instead.) > > LINUXLIBC6 is yellow, but this looks ok: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 > > Do they have to be more recent? Or need last release and last ok? > I only do last ok. You don't have last release for AMD64_LINUX, it > doesn't exist, but are green. > Maybe two separate builds are needed? > > SPARC32_LINUX is yellow but it also looks ok. > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 Tinderbox shows running builds that haven't complete yet in yellow. Results are either green, red, or orange. So the result transfer to the server may have failed. > The most recent completed PPC_LINUX failed to get much of the source > tree in the CVS checkout. That happens often. I should probably put > in a retry or something.. No. You should probably do something about your network connection ;-) BTW, the exit you put in after the cvs checkout won't work this way. Unless you use special bash pipe result evaluation, it's always the _last_ process in a pipe that determines its result code. > (Bringing back I386_DARWIN, funny thing there, is that to compile X > client, you need Python, and the in-box one isn't new enough, and > current doesn't build out of the box because it assumes a full Mac > system..still working on it..) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 11:19:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 09:19:42 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: Looking at your Hudson jobs..to create my own.. I notice you run test_m3tests manually. I'll try that. Maybe of the yellow jobs ran to completion..but maybe because I didn't run test_m3tests? - Jay ---------------------------------------- > Date: Sun, 26 Jul 2009 11:17:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Tinderbox/Hudson > > Quoting Jay K : > >> - The links to my Tinderbox test results don't work. >> >> - Why are my Tinderbox status usually yellow even though the logs look ok? >> Due the missing test results? >> >> - I do already have Hudson server running OpenBSD/x86, that was >> easy, not configured yet (still cross building cm3 and will try a >> Tinderbox run first instead.) >> >> LINUXLIBC6 is yellow, but this looks ok: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >> >> Do they have to be more recent? Or need last release and last ok? >> I only do last ok. You don't have last release for AMD64_LINUX, it >> doesn't exist, but are green. >> Maybe two separate builds are needed? >> >> SPARC32_LINUX is yellow but it also looks ok. >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 > > Tinderbox shows running builds that haven't complete yet in yellow. > Results are either green, red, or orange. So the result transfer to > the server may have failed. > >> The most recent completed PPC_LINUX failed to get much of the source >> tree in the CVS checkout. That happens often. I should probably put >> in a retry or something.. > > No. You should probably do something about your network connection ;-) > > BTW, the exit you put in after the cvs checkout won't work this way. > Unless you use special bash pipe result evaluation, it's always the > _last_ process in a pipe that determines its result code. > >> (Bringing back I386_DARWIN, funny thing there, is that to compile X >> client, you need Python, and the in-box one isn't new enough, and >> current doesn't build out of the box because it assumes a full Mac >> system..still working on it..) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 26 12:07:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 10:07:51 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: I'm running Tinderbox on SOLgnu now. It fails with that error without a change and gets past the first email if I change the date commands. The first cvs checkout eventually failed, trying again.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Fwd: Output from "cron" command > Date: Sun, 26 Jul 2009 03:09:59 +0000 > > > Tony reverted it. I'm bringing my Solaris/sparc machine up to date and will try running Tinderbox. > I will likely try with plain date and see what happens there and otherwise. > > - Jay > > > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 22:00:15 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Quoting Tony Hosking : >> >>> I've not changed anything on my side. >> >> I don't understand why I missed that: >> >> revision 1.13 >> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >> let's just try plain date, based on the choices in the error message >> ---------------------------- >> >> But you seem to have fixed it already: >> >> revision 1.14 >> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >> Revert to what used to work. >> >> Strange that it didn't show up in my first diff. >> >> Olaf >> >> >>> >>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>> >>>> I don't see how that will help us... It worked for Tony for over >>>> a year, and nothing obvious has changed. Or did something change on >>>> your side, Tony (system upgrade, path setting, ...)? >>>> >>>> It's not good to introduce arbitrary changes now without understanding >>>> why it breaks. >>>> >>>> Olaf >>>> >>>> Quoting Jay K : >>>> >>>>> >>>>> Can I suggest the portable scripting language C? >>>>> >>>>> >>>>> -bash-3.00$ cat date.c >>>>> #include >>>>> #include >>>>> #include >>>>> int main() >>>>> { >>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>> return 0; >>>>> } >>>>> -bash-3.00$ cc date.c -o ./mydate >>>>> -bash-3.00$ ./mydate >>>>> 1248549753 >>>>> -bash-3.00$ pwd >>>>> /dev2/cm3/scripts >>>>> >>>>> >>>>> use that instead? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>> >>>>>> >>>>>> (two occurences of that) >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>> >>>>>>> >>>>>>> This line: >>>>>>> >>>>>>> >>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>> >>>>>>> needs to more like these lines: >>>>>>> >>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>> >>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>> run done." >>>>>>> >>>>>>> >>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>> 2009.07.25 12:13:54 >>>>>>> >>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>> 07.25.09 12:14:33 >>>>>>> >>>>>>> -bash-3.00$ date +%s >>>>>>> %s >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>> From: wagner at elegosoft.com >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>> >>>>>>>> Quoting Tony Hosking : >>>>>>>> >>>>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>>>> parameter to the "date" command. >>>>>>>>> >>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>> >>>>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>>>> the one before succeeded: >>>>>>>> >>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>> >>>>>>>> I was hoping to get a green build from one of your systems today >>>>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>>>> But if you cannot send your results to the tinderbox that will be >>>>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>>>> working. >>>>>>>> >>>>>>>> The error below seems to be that the reported start time is 0, and >>>>>>>> that cannot be according to the source. Could you set -x at the start >>>>>>>> of the tinderbox script and try again? >>>>>>>> >>>>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>>>> problem? >>>>>>>> >>>>>>>> Olaf >>>>>>>> >>>>>>>>> -- Tony (not mobile) >>>>>>>> :-) >>>>>>>> >>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>> >>>>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>>>> someone restore? >>>>>>>>>> >>>>>>>>>> Hi Tony, >>>>>>>>>> >>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>> *************** >>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>> date 'date +%s'" >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>> >>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>> >>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>> *************** >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>> *************** >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Begin forwarded message: >>>>>>>>>>> >>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>> >>>>>>>>>>>> produced the following output: >>>>>>>>>>>> >>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>> Building cm3. >>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>> >>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>>>> >>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>> >>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>>> >>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>> >>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>> Building cm3. >>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>> >>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>> >>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>> >>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>>> >>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>> 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>> Sitz: Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>>> DE163214194 >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>> 23 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>> IdNr: DE163214194 >>>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sun Jul 26 12:49:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 12:49:49 +0200 Subject: [M3devel] CM3 release engineering status Message-ID: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> Here's the current status: * release branch created for 5.8 * Hudson continuous integration and Tinderbox default checkout changed to the release branch by default (instances out of my control) * end of code freeze on main trunk (seems it never crossed the 0 degree Celsius boundary anyway :-) * commit restriction for the release branch: - contact me for including changes there - needed: CVS start and end tag exactly identifying the change set to be included * reviewed all package test failures and fixed them (for FreeBSD4 and AMD64_LINUX) * only known good target platforms currently are FreeBSD4 and AMD64_LINUX * need status for at least LINUXLIBC6, NT386, SOLgnu additionally * will try to setup more regression testing under my control during the next week(s) * RC2 postponed until end of next week... hopefully we'll know more then see also https://projects.elego.de/cm3/roadmap and http://hudson.modula3.com:8080/view/cm3/ Thanks for your attention and cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 13:04:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 11:04:06 +0000 Subject: [M3devel] new errors wrt bc and [ Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248604850.21111 1) m3gdb/src/m3makefile gnu platform missing, I fixed it 2a) "/home/jay/work/cm3-ws/sparc3-2009-07-26-03-59-12/cm3/m3-sys/m3tests/src/m3makefile", line 279: quake runtime error: execution failed: execution of `bc? failed: errno=2 2b) /home/jay/work/cm3-ws/sparc3-2009-07-26-03-59-12/cm3/scripts/pkgmap.sh: line 360: bc: command not found 3) regression-scripts/defs.sh: line 776: [: too many arguments if [ "${TESTHOSTNAME}" = "birch.elegosoft.com" -a `who -m | cut -d ' ' -f1` = "m3" ]; then Maybe put an "x" in there? if [ "x${TESTHOSTNAME}" = "xbirch.elegosoft.com" -a `who -m | cut -d ' ' -f1` = "m3" ]; then ? (+2 for using Python..) - Jay From jay.krell at cornell.edu Sun Jul 26 14:48:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 12:48:20 +0000 Subject: [M3devel] the formsedit crash Message-ID: Ok here is the formsedit crash. This is on SOLgnu. I have also seen it on either PPC_DARWIN or PPC_LINUX. I can try those again. It doesn't happen every time, but some large fraction, like maybe half. I changed the SIGsEGV to an assertion failure. -bash-3.00$ export DISPLAY=192.168.1.120:0.0 -bash-3.00$ ./formsedit *** *** runtime error: *** failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 *** Abort (core dumped) You can't debug it live because you keep getting interrupted by sig usr2. -bash-3.00$ dbx formsedit core t at 1 (l at 1) terminated by signal KILL (Killed) 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! 0xfe3c00a4 These statements from the debugger about main/AddUnit don't make sense to me. Current function is main 13 RTLinker__AddUnit (FormsEdit_M3); (dbx) where current thread: t at 1 [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xfe4680b8 [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xfe467ca0 [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xfefa5adc Does the code really recurse like this? [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, 0xffbf9ca0, 0xfe4a5d 00, 0xfef48180), at 0xfef48520 [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, 0xff000000, 0x0, 0x0 ), at 0xff046ea4 [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, 0xffbf9e48, 0x0, 0xfefbcf58), at 0xfefbcf84 [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, 0xffbf9f18, 0 x0, 0xff0437d8), at 0xff043864 [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, 0x0, 0x0), at 0xff046ea4 [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, 0xffbfa0a8, 0x0, 0xfefbcf58), at 0xfefbcf84 [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, 0x0, 0x0), at 0xff046ea4 [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, 0xffbfa238, 0x0, 0xfefbcf58), at 0xfefbcf84 [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, 0x0, 0x0), at 0xff046ea4 [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, 0xffbfa3c8, 0x0, 0xfefbcf58), at 0xfefbcf84 [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, 0x0, 0x0), at 0xff046ea4 [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, 0xffbfa558, 0x0, 0xfefbcf58), at 0xfefbcf84 [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, 0x0, 0x0), at 0xff046ea4 [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, 0xffbfa6e8, 0x0, 0xfefbcf58), at 0xfefbcf84 [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, 0x0, 0x0), at 0xff046ea4 [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, 0xffbfa878, 0x0, 0xfefbcf58), at 0xfefbcf84 [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, 0x0, 0x0), at 0xff046ea4 [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, 0xffbfaa08, 0x0, 0xfefbcf58), at 0xfefbcf84 [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, 0x0, 0x0), at 0xff046ea4 [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, 0xffbfab98, 0x0, 0xfefbcf58), at 0xfefbcf84 [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, 0x0, 0x0), at 0xff046ea4 [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, 0xffbfad28, 0x0, 0xfefbcf58), at 0xfefbcf84 [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, 0x0, 0x0), at 0xff046ea4 [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, 0xffbfaeb8, 0x0, 0xfefbcf58), at 0xfefbcf84 [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, 0x0, 0x0), at 0xff046ea4 [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, 0xffbfb048, 0x0, 0xfefbcf58), at 0xfefbcf84 [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, 0x0, 0x0), at 0xff046ea4 [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, 0xffbfb1d8, 0x0, 0xfefbcf58), at 0xfefbcf84 [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, 0x0, 0x0), at 0xff046ea4 [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, 0xffbfb368, 0x0, 0xfefbcf58), at 0xfefbcf84 [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, 0x0, 0x0), at 0xff046ea4 [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, 0xffbfb4f8, 0x0, 0xfefbcf58), at 0xfefbcf84 [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, 0x0, 0x0), at 0xff046ea4 [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, 0xffbfb688, 0x0, 0xfefbcf58), at 0xfefbcf84 [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, 0x0, 0x0), at 0xff046ea4 [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, 0xffbfb818, 0x0, 0xfefbcf58), at 0xfefbcf84 [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, 0x0, 0x0), at 0xff046ea4 [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, 0xffbfb9a8, 0x0, 0xfefbcf58), at 0xfefbcf84 [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, 0x0, 0x0), at 0xff046ea4 [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, 0xffbfbb38, 0x0, 0xfefbcf58), at 0xfefbcf84 [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, 0x0, 0x0), at 0xff046ea4 [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, 0xffbfbcc8, 0x0, 0xfefbcf58), at 0xfefbcf84 [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, 0x0, 0x0), at 0xff046ea4 [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, 0xffbfbe58, 0x0, 0xfefbcf58), at 0xfefbcf84 [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, 0x0, 0x0), at 0xff046ea4 [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, 0xffbfbfe8, 0x0, 0xfefbcf58), at 0xfefbcf84 [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, 0x0, 0x0), at 0xff046ea4 [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, 0xffbfc178, 0x0, 0xfefbcf58), at 0xfefbcf84 [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, 0x0, 0x0), at 0xff046ea4 [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, 0xffbfc308, 0x0, 0xfefbcf58), at 0xfefbcf84 [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, 0x0, 0x0), at 0xff046ea4 [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, 0xffbfc498, 0x0, 0xfefbcf58), at 0xfefbcf84 [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, 0xfe1b2000, 0x6b170 , 0x0), at 0xff046ea4 [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, 0xff000000, 0x0, 0x0), at 0xff191d20 [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b27 0, 0x0), at 0xfefb6a38 [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d00, 0x0), at 0xfefbc9f4 [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, 0xfe1b2000, 0x6b290, 0x0), at 0xfefbc9f4 [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b2b 0, 0x0), at 0xfefb6a38 [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d00, 0x0), at 0xfefbc9f4 [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, 0xfe1b2000, 0x6b2d0, 0x0), at 0xfefbc9f4 [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6af7 0, 0x0), at 0xfefb6a38 [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, 0xff000000, 0x0, 0x0), at 0xfefbc9f4 [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b33 0, 0x0), at 0xfefb6a38 [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, 0xfe1b2000, 0x6b698, 0x0), at 0xfefbc9f4 [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, 0xfe1b2000, 0x6b69 8, 0x0), at 0xfefbc9f4 [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, 0xfe1b2000, 0xf e4a5d00, 0x0), at 0xfefeb348 [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, 0xfe1b2000, 0x6b6b8, 0x0), at 0xfefbc9f4 [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b7f 8, 0x0), at 0xfefb6a38 [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, 0xfe1b2000, 0x6b858, 0x0), at 0xfefbc9f4 [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, 0x0, 0x0), at 0xfefb6a38 [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, 0xfe1b2000, 0x6b858, 0x0), at 0xfefbc9f4 [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, 0xff000000, 0x0 , 0x0), at 0xff18d2ec [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b87 8, 0x0), at 0xfefb6a38 [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b898, 0x0), at 0xfefbc9f4 [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, 0xfe1b2000, 0x6b89 8, 0x0), at 0xfefbc9f4 [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, 0xfe1b2000, 0x6 b8b8, 0x0), at 0xfefeb348 [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, 0x20, 0xffbfd b20), at 0xfefb6a38 [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, 0xfe1b2000, 0x6b8b8, 0x0), at 0xfefbc9f4 [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xff01f884 [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, 0xfe1b2000, 0x6b8d8, 0x0), at 0xfefbc9f4 [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xff19e338 [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, 0xfe1b2000, 0x60338, 0x0), at 0xfefbc9f4 [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d 00, 0x0), at 0xfeff6db4 [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, 0xfe1b2000 , 0x6e5a0, 0x0), at 0xfefbc9f4 (dbx) (dbx) threads > t at 1 a l at 1 ?() LWP suspended in __lwp_park() t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in ___nanosleep () t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 in __lwp_pa rk() t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in ___nanosleep () t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 in __lwp_pa rk() t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 in __lwp_pa rk() t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 in __lwp_pa rk() o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in __lwp_kill( ) t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 in __lwp_pa rk() (dbx) The crashing thread: (dbx) thread t at 27 t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe3c11f4 (dbx) where current thread: t at 27 =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at 0xfe35fdd8 [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at 0xfe33fff8 [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at 0xfe46255c [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at 0xfe4529c8 [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, 0xfddf0900), at 0x fe44f2e4 [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, 0xfe4b4d90, 0xff2 50434), at 0xfe44ee5c [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, 0x100000), at 0xfe44fa0c [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678), at 0xfe44f590 [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc53131), at 0xfe44f44c [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, 0x0), at 0xfe46 470c [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678), at 0xfe44f680 [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc53661), at 0xfe44f44c [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc538 e1), at 0xfe46470c [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, 0xfdc53a40, 0xfdc539 2c, 0xfdc53928), at 0xfe42ffe0 [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, 0xfdc53a40), a t 0xff141d64 (too many frames for an assertion failure imho!) [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xff13dda4 [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, 0xff000000, 0x0, 0x0), at 0xff13d9e8 [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, 0xfddf0800, 0x69da0, 0x0), at 0xff140730 [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0xff000000, 0xff00000 0, 0x0, 0x1), at 0xff1407d0 [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, 0xfdd221bc), a t 0xfefb8f04 [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at 0xfefc5170 [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, 0xfddf0800, 0x90 410, 0x0), at 0xfefc45a8 [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfefc4674 [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at 0xfe46bc00 [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, 0xfe46b740, 0x1) , at 0xfe46b790 (dbx) - Jay From jay.krell at cornell.edu Sun Jul 26 16:10:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 14:10:50 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: I don't think that is it but I don't know. I don't know the various paths through the scripts, haven't studied them enough.. for some reason my one run on SOLgnu did run the tests and turned green. Most of my runs stop after successful compile so stay yellow. I edited out that one line you said to. Maybe I should an -x run. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Tinderbox/Hudson > Date: Sun, 26 Jul 2009 09:19:42 +0000 > > > Looking at your Hudson jobs..to create my own.. I notice you run test_m3tests manually. I'll try that. > Maybe of the yellow jobs ran to completion..but maybe because I didn't run test_m3tests? > > - Jay > > > > ---------------------------------------- >> Date: Sun, 26 Jul 2009 11:17:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Tinderbox/Hudson >> >> Quoting Jay K : >> >>> - The links to my Tinderbox test results don't work. >>> >>> - Why are my Tinderbox status usually yellow even though the logs look ok? >>> Due the missing test results? >>> >>> - I do already have Hudson server running OpenBSD/x86, that was >>> easy, not configured yet (still cross building cm3 and will try a >>> Tinderbox run first instead.) >>> >>> LINUXLIBC6 is yellow, but this looks ok: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >>> >>> Do they have to be more recent? Or need last release and last ok? >>> I only do last ok. You don't have last release for AMD64_LINUX, it >>> doesn't exist, but are green. >>> Maybe two separate builds are needed? >>> >>> SPARC32_LINUX is yellow but it also looks ok. >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 >> >> Tinderbox shows running builds that haven't complete yet in yellow. >> Results are either green, red, or orange. So the result transfer to >> the server may have failed. >> >>> The most recent completed PPC_LINUX failed to get much of the source >>> tree in the CVS checkout. That happens often. I should probably put >>> in a retry or something.. >> >> No. You should probably do something about your network connection ;-) >> >> BTW, the exit you put in after the cvs checkout won't work this way. >> Unless you use special bash pipe result evaluation, it's always the >> _last_ process in a pipe that determines its result code. >> >>> (Bringing back I386_DARWIN, funny thing there, is that to compile X >>> client, you need Python, and the in-box one isn't new enough, and >>> current doesn't build out of the box because it assumes a full Mac >>> system..still working on it..) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sun Jul 26 19:16:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 17:16:49 +0000 Subject: [M3devel] libz in Tinderbox? Message-ID: Tony can you install libz? Or should we import it? Or should we maybe probe for $HOME/lib/libz.a or somewhere else? http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake runtime error: file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib 22072 There is also: Must be attached to terminal for ?am I? option 49575 + [ niagara = birch.elegosoft.com -a = m3 ] 49576 ./tinderbox-build.sh: test: argument expected 49577 r4=1 49578 + expr 0 + 0 + 255 + 255 + 1 49579 + return 511 49580 + date +%Y.%m.%d %H:%M:%S 49581 + echo [end run-tests 2009.07.26 10:39:00] 49582 [end run-tests 2009.07.26 10:39:00] 49583 *** TESTS FAILED - Jay From hosking at cs.purdue.edu Sun Jul 26 19:44:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:44:39 -0400 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> It did not used to be required that to build X clients on I386_DARWIN you needed Python. What changed? Sent from my iPhone On Jul 26, 2009, at 5:17 AM, Olaf Wagner wrote: > Quoting Jay K : > >> - The links to my Tinderbox test results don't work. >> >> - Why are my Tinderbox status usually yellow even though the logs >> look ok? >> Due the missing test results? >> >> - I do already have Hudson server running OpenBSD/x86, that was >> easy, not configured yet (still cross building cm3 and will try a >> Tinderbox run first instead.) >> >> LINUXLIBC6 is yellow, but this looks ok: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >> >> Do they have to be more recent? Or need last release and last ok? >> I only do last ok. You don't have last release for AMD64_LINUX, it >> doesn't exist, but are green. >> Maybe two separate builds are needed? >> >> SPARC32_LINUX is yellow but it also looks ok. >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 > > Tinderbox shows running builds that haven't complete yet in yellow. > Results are either green, red, or orange. So the result transfer to > the server may have failed. > >> The most recent completed PPC_LINUX failed to get much of the >> source tree in the CVS checkout. That happens often. I should >> probably put in a retry or something.. > > No. You should probably do something about your network connection ;-) > > BTW, the exit you put in after the cvs checkout won't work this way. > Unless you use special bash pipe result evaluation, it's always the > _last_ process in a pipe that determines its result code. > >> (Bringing back I386_DARWIN, funny thing there, is that to compile >> X client, you need Python, and the in-box one isn't new enough, >> and current doesn't build out of the box because it assumes a full >> Mac system..still working on it..) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Sun Jul 26 19:48:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:48:35 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> I have not changed my tinderbox install on niagara for over a year and it suddenly stopped working so the problem must be with some recent commit. Note that I installed the GNU binutils way back when (over a year ago) so that things would work with 'date +%s'. Sent from my iPhone On Jul 26, 2009, at 6:07 AM, Jay K wrote: > > I'm running Tinderbox on SOLgnu now. > It fails with that error without a change and gets past the first > email if I change the date commands. > The first cvs checkout eventually failed, trying again.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sun, 26 Jul 2009 03:09:59 +0000 >> >> >> Tony reverted it. I'm bringing my Solaris/sparc machine up to date >> and will try running Tinderbox. >> I will likely try with plain date and see what happens there and >> otherwise. >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 22:00:15 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> I've not changed anything on my side. >>> >>> I don't understand why I missed that: >>> >>> revision 1.13 >>> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >>> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >>> let's just try plain date, based on the choices in the error message >>> ---------------------------- >>> >>> But you seem to have fixed it already: >>> >>> revision 1.14 >>> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >>> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >>> Revert to what used to work. >>> >>> Strange that it didn't show up in my first diff. >>> >>> Olaf >>> >>> >>>> >>>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>>> >>>>> I don't see how that will help us... It worked for Tony for over >>>>> a year, and nothing obvious has changed. Or did something change >>>>> on >>>>> your side, Tony (system upgrade, path setting, ...)? >>>>> >>>>> It's not good to introduce arbitrary changes now without >>>>> understanding >>>>> why it breaks. >>>>> >>>>> Olaf >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> >>>>>> Can I suggest the portable scripting language C? >>>>>> >>>>>> >>>>>> -bash-3.00$ cat date.c >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> int main() >>>>>> { >>>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>>> return 0; >>>>>> } >>>>>> -bash-3.00$ cc date.c -o ./mydate >>>>>> -bash-3.00$ ./mydate >>>>>> 1248549753 >>>>>> -bash-3.00$ pwd >>>>>> /dev2/cm3/scripts >>>>>> >>>>>> >>>>>> use that instead? >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>> >>>>>>> >>>>>>> (two occurences of that) >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>>> >>>>>>>> >>>>>>>> This line: >>>>>>>> >>>>>>>> >>>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>>> >>>>>>>> needs to more like these lines: >>>>>>>> >>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>>> >>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>>> run done." >>>>>>>> >>>>>>>> >>>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>>> 2009.07.25 12:13:54 >>>>>>>> >>>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>>> 07.25.09 12:14:33 >>>>>>>> >>>>>>>> -bash-3.00$ date +%s >>>>>>>> %s >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>>> From: wagner at elegosoft.com >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>>> >>>>>>>>> Quoting Tony Hosking : >>>>>>>>> >>>>>>>>>> Perhaps I am confusing with the original change I made for >>>>>>>>>> 1.10 to the >>>>>>>>>> parameter to the "date" command. >>>>>>>>>> >>>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>>> properly. It's been a long time since I've seen a sane >>>>>>>>>> tinderbox run >>>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>>> >>>>>>>>> I broke the last one yesterday with $() (fixed soon >>>>>>>>> afterwards), but >>>>>>>>> the one before succeeded: >>>>>>>>> >>>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>>> >>>>>>>>> I was hoping to get a green build from one of your systems >>>>>>>>> today >>>>>>>>> (big-endian, different architecture) to finally fix the RC2 >>>>>>>>> tag. >>>>>>>>> But if you cannot send your results to the tinderbox that >>>>>>>>> will be >>>>>>>>> difficult :-/ I really don't understand why that should have >>>>>>>>> stopped >>>>>>>>> working. >>>>>>>>> >>>>>>>>> The error below seems to be that the reported start time is >>>>>>>>> 0, and >>>>>>>>> that cannot be according to the source. Could you set -x at >>>>>>>>> the start >>>>>>>>> of the tinderbox script and try again? >>>>>>>>> >>>>>>>>> Jay, can you think of anything you have changed that may >>>>>>>>> cause Tony's >>>>>>>>> problem? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>>> -- Tony (not mobile) >>>>>>>>> :-) >>>>>>>>> >>>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>>> >>>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>>> >>>>>>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>>>>>> ago. Can >>>>>>>>>>>> someone restore? >>>>>>>>>>> >>>>>>>>>>> Hi Tony, >>>>>>>>>>> >>>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>> *************** >>>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>>> date 'date +%s'" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: >>>>>>>>>>> $STARTTIME >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>>> >>>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>>> >>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>> Jul-09 >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>> *************** >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>>> *************** >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did >>>>>>>>>>> you change >>>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>> >>>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>>> >>>>>>>>>>>>> produced the following output: >>>>>>>>>>>>> >>>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>>> >>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>>>>>> log.txt >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: >>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>> clock >>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>> time. >>>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>>>>>> minutes) >>>>>>>>>>>>> >>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023- >>>>>>>>>>>>> tVaq2V ... >>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>> *.tgz >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>> >>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>>> >>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>>>>>> log.txt >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: >>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>> clock >>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>> time. >>>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>>> >>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032- >>>>>>>>>>>>> xba4dW ... >>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>> *.tgz >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>>> 45 86 95 >>>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>>> Sitz: Berlin >>>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>>> IdNr: >>>>>>>>>>> DE163214194 >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wag >>>>>>>>> ner | Sitz: Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>> IdNr: DE163214194 >>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Si >>>>> tz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> From hosking at cs.purdue.edu Sun Jul 26 19:50:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:50:34 -0400 Subject: [M3devel] CM3 release engineering status In-Reply-To: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> References: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> Message-ID: <47F8AD91-A3A4-41F6-BB4C-4705BB2DD5DB@cs.purdue.edu> +I386_DARWIN right? Sent from my iPhone On Jul 26, 2009, at 6:49 AM, Olaf Wagner wrote: > Here's the current status: > > * release branch created for 5.8 > * Hudson continuous integration and Tinderbox default checkout > changed to the release branch by default (instances out of my > control) > * end of code freeze on main trunk (seems it never crossed the 0 > degree > Celsius boundary anyway :-) > * commit restriction for the release branch: > - contact me for including changes there > - needed: CVS start and end tag exactly identifying the change set > to be included > * reviewed all package test failures and fixed them (for FreeBSD4 and > AMD64_LINUX) > * only known good target platforms currently are FreeBSD4 and > AMD64_LINUX > * need status for at least LINUXLIBC6, NT386, SOLgnu additionally > * will try to setup more regression testing under my control during > the next week(s) > * RC2 postponed until end of next week... hopefully we'll know more > then > > see also https://projects.elego.de/cm3/roadmap > and http://hudson.modula3.com:8080/view/cm3/ > > Thanks for your attention and cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Sun Jul 26 19:57:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:57:07 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: Message-ID: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Stack overflow? And yes, I have seen deep recursions like that. What happens if you use a deeper stack? Sent from my iPhone On Jul 26, 2009, at 8:48 AM, Jay K wrote: > > Ok here is the formsedit crash. > This is on SOLgnu. I have also seen it on either PPC_DARWIN or > PPC_LINUX. > I can try those again. > > > It doesn't happen every time, but some large fraction, like maybe > half. > I changed the SIGsEGV to an assertion failure. > > > -bash-3.00$ export DISPLAY=192.168.1.120:0.0 > -bash-3.00$ ./formsedit > > *** > *** runtime error: > *** failed. > *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 > *** > Abort (core dumped) > > You can't debug it live because you keep getting interrupted by sig > usr2. > > -bash-3.00$ dbx formsedit core > > t at 1 (l at 1) terminated by signal KILL (Killed) > 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! > 0xfe3c00a4 > > These statements from the debugger about main/AddUnit don't make > sense to me. > > Current function is main > 13 RTLinker__AddUnit (FormsEdit_M3); > > (dbx) where > current thread: t at 1 > [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 > [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 > [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xfe4680b8 > [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at > 0xfe467ca0 > [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at > 0xfefa5adc > > Does the code really recurse like this? > > [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, > 0xffbf9ca0, 0xfe4a5d > 00, 0xfef48180), at 0xfef48520 > [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, > 0xff000000, 0x0, 0x0 > ), at 0xff046ea4 > [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, > 0xffbf9e48, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, > 0xffbf9f18, 0 > x0, 0xff0437d8), at 0xff043864 > [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, > 0xffbfa0a8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, > 0xffbfa238, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, > 0xffbfa3c8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, > 0xffbfa558, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, > 0xffbfa6e8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, > 0xffbfa878, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, > 0xffbfaa08, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, > 0xffbfab98, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, > 0xffbfad28, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, > 0xffbfaeb8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, > 0xffbfb048, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, > 0xffbfb1d8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, > 0xffbfb368, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, > 0xffbfb4f8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, > 0xffbfb688, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, > 0xffbfb818, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, > 0xffbfb9a8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, > 0xffbfbb38, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, > 0xffbfbcc8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, > 0xffbfbe58, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, > 0xffbfbfe8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, > 0xffbfc178, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, > 0xffbfc308, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, > 0xffbfc498, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, > 0xfe1b2000, 0x6b170 > , 0x0), at 0xff046ea4 > [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, > 0xff000000, > 0x0, 0x0), at 0xff191d20 > [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b27 > 0, 0x0), at 0xfefb6a38 > [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, > 0xfe1b2000, > 0xfe4a5d00, 0x0), at 0xfefbc9f4 > [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b290, 0x0), at 0xfefbc9f4 > [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b2b > 0, 0x0), at 0xfefb6a38 > [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, > 0xfe1b2000, > 0xfe4a5d00, 0x0), at 0xfefbc9f4 > [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b2d0, 0x0), at 0xfefbc9f4 > [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6af7 > 0, 0x0), at 0xfefb6a38 > [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, > 0xff000000, > 0x0, 0x0), at 0xfefbc9f4 > [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b33 > 0, 0x0), at 0xfefb6a38 > [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b698, 0x0), at 0xfefbc9f4 > [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, > 0xfe1b2000, 0x6b69 > 8, 0x0), at 0xfefbc9f4 > [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, > 0xfe1b2000, 0xf > e4a5d00, 0x0), at 0xfefeb348 > [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b6b8, 0x0), at 0xfefbc9f4 > [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b7f > 8, 0x0), at 0xfefb6a38 > [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b858, 0x0), at 0xfefbc9f4 > [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, > 0x0, 0x0), at > 0xfefb6a38 > [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b858, 0x0), at 0xfefbc9f4 > [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, > 0xff000000, 0x0 > , 0x0), at 0xff18d2ec > [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b87 > 8, 0x0), at 0xfefb6a38 > [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b898, 0x0), at 0xfefbc9f4 > [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, > 0xfe1b2000, 0x6b89 > 8, 0x0), at 0xfefbc9f4 > [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, > 0xfe1b2000, 0x6 > b8b8, 0x0), at 0xfefeb348 > [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, > 0x20, 0xffbfd > b20), at 0xfefb6a38 > [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, > 0xfe1b2000, > 0x6b8b8, 0x0), at 0xfefbc9f4 > [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xff01f884 > [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b8d8, 0x0), at 0xfefbc9f4 > [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xff19e338 > [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, > 0xfe1b2000, > 0x60338, 0x0), at 0xfefbc9f4 > [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4a5d > 00, 0x0), at 0xfeff6db4 > [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, > 0xfe1b2000 > , 0x6e5a0, 0x0), at 0xfefbc9f4 > (dbx) > (dbx) threads >> t at 1 a l at 1 ?() LWP suspended in __lwp_park() > t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in > ___nanosleep > () > t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 > in __lwp_pa > rk() > t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in > ___nanosleep > () > t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 > in __lwp_pa > rk() > t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 > in __lwp_pa > rk() > t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 > in __lwp_pa > rk() > o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in > __lwp_kill( > ) > t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 > in __lwp_pa > rk() > (dbx) > > > The crashing thread: > > (dbx) thread t at 27 > t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 > 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xfe3c11f4 > (dbx) where > current thread: t at 27 > =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 > [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at > 0xfe35fdd8 > [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at > 0xfe33fff8 > [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at > 0xfe46255c > [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at > 0xfe4529c8 > [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, > 0xfddf0900), at 0x > fe44f2e4 > [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, > 0xfe4b4d90, 0xff2 > 50434), at 0xfe44ee5c > [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, > 0x100000), > at 0xfe44fa0c > [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 > ), > at 0xfe44f590 > [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, > 0xfffffff8, 0x0, > 0xfdc53131), at 0xfe44f44c > [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, > 0x0), at 0xfe46 > 470c > [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 > ), > at 0xfe44f680 > [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, > 0xfffffff8, 0x0, > 0xfdc53661), at 0xfe44f44c > [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, > 0x0, 0xfdc538 > e1), at 0xfe46470c > [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, > 0xfdc53a40, 0xfdc539 > 2c, 0xfdc53928), at 0xfe42ffe0 > [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, > 0xfdc53a40), a > t 0xff141d64 > > (too many frames for an assertion failure imho!) > > > [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, > 0x1000, 0x0, > 0x0), at 0xff13dda4 > [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, > 0xff000000, 0x0, > 0x0), at 0xff13d9e8 > [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, > 0xfddf0800, > 0x69da0, 0x0), at 0xff140730 > [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, > 0xff000000, 0xff00000 > 0, 0x0, 0x1), at 0xff1407d0 > [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, > 0xfdd221bc), a > t 0xfefb8f04 > [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at > 0xfefc5170 > [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, > 0xfddf0800, 0x90 > 410, 0x0), at 0xfefc45a8 > [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at > 0xfefc4674 > [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at > 0xfe46bc00 > [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, > 0xfe46b740, 0x1) > , at 0xfe46b790 > (dbx) > > > - Jay From jay.krell at cornell.edu Sun Jul 26 19:57:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 17:57:14 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> Message-ID: X clients as in the X client libraries themselves Xlib.so et. al. -- as opposed to the X server. Actually apparently Xlib has been partly replaced by xcb, X C bindings. It is not a Modula-3 thing. But it is interesting imho. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Sun, 26 Jul 2009 13:44:39 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] Tinderbox/Hudson > > It did not used to be required that to build X clients on I386_DARWIN > you needed Python. What changed? > > Sent from my iPhone > > On Jul 26, 2009, at 5:17 AM, Olaf Wagner wrote: > >> Quoting Jay K : >> >>> - The links to my Tinderbox test results don't work. >>> >>> - Why are my Tinderbox status usually yellow even though the logs >>> look ok? >>> Due the missing test results? >>> >>> - I do already have Hudson server running OpenBSD/x86, that was >>> easy, not configured yet (still cross building cm3 and will try a >>> Tinderbox run first instead.) >>> >>> LINUXLIBC6 is yellow, but this looks ok: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >>> >>> Do they have to be more recent? Or need last release and last ok? >>> I only do last ok. You don't have last release for AMD64_LINUX, it >>> doesn't exist, but are green. >>> Maybe two separate builds are needed? >>> >>> SPARC32_LINUX is yellow but it also looks ok. >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 >> >> Tinderbox shows running builds that haven't complete yet in yellow. >> Results are either green, red, or orange. So the result transfer to >> the server may have failed. >> >>> The most recent completed PPC_LINUX failed to get much of the >>> source tree in the CVS checkout. That happens often. I should >>> probably put in a retry or something.. >> >> No. You should probably do something about your network connection ;-) >> >> BTW, the exit you put in after the cvs checkout won't work this way. >> Unless you use special bash pipe result evaluation, it's always the >> _last_ process in a pipe that determines its result code. >> >>> (Bringing back I386_DARWIN, funny thing there, is that to compile >>> X client, you need Python, and the in-box one isn't new enough, >>> and current doesn't build out of the box because it assumes a full >>> Mac system..still working on it..) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ >> any >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be >> rlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> From hosking at cs.purdue.edu Sun Jul 26 20:00:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:00:14 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <200907261557.n6QFvTIu008442@niagara.cs.purdue.edu> Message-ID: I haven't digested this closely, but here is the latest niagara tinderbox log with +x. Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: July 26, 2009 11:57:29 AM EDT > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > + trap cleanup 1 2 3 6 > + [ -z cm3.build ] > + . cm3.build > PROJECT=cm3 > TREENAME=cm3 > BUILD_REL=rel > BUILD_REL_NAME=rel > REGRESSION_SCRIPTS_DIR=regression-scripts > + [ rel = rel ] > BUILD_REL_NAME=release > + hostname > + [ -f ~/cm3/niagara.cs.purdue.edu.conf ] > CVSROOT=:ext:modula3.elegosoft.com:/usr/cvs > + cvs -d :ext:modula3.elegosoft.com:/usr/cvs checkout -A -d > regression-scripts cm3/scripts/regression/defs.sh > U regression-scripts/defs.sh > + test -r regression-scripts/defs.sh > + . regression-scripts/defs.sh > + sed -e s/\..*//+ hostname > > TESTHOSTNAME=niagara > HTMP=/homes/hosking/tmp/cm3/niagara > + tr -d+ date\n -u > +%Y-%m-%d-%H-%M-%S > DS=2009-07-26-10-30-05 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > COVERSION=-P -r release_branch_cm3_5_8 > LASTREL=5.4.0 > INSTBASE=/homes/hosking/work/cm3-inst/niagara > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + test x != x > CM3CVSUSER_AT= > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > WWWSERVER=birch.elegosoft.com > RLOG=/homes/hosking/tmp/cm3/niagara/cm3-rlog-2009-07-26-10-30-05 > CM3_NKEEP=7 > + uname > UNAME=SunOS > + uname -m > UNAMEM=sun4v > TMP=/tmp > TMPDIR=/tmp > + [ ! -d /tmp ] > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > M3TOUT=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-10-30-05.stdout > M3TERR=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-10-30-05.stderr > CM3_VERSION=* > CM3_SNAPSHOT=/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu- > *-2009-07-26-10-30-05.tgz > HTML_REPORT=/tmp/cm3-pkg-report-SOLgnu-2009-07-26-10-30-05.html > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_LOC=/homes/hosking/work > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_URL=http://modula3.elegosoft.com/cm3 > + echo TESTHOSTNAME=niagara > TESTHOSTNAME=niagara > + echo WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > + echo LASTREL=5.4.0 > LASTREL=5.4.0 > + echo INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > + echo INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > + echo INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > + echo INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + echo CM3_OSTYPE=POSIX > CM3_OSTYPE=POSIX > + echo CM3_TARGET=SOLgnu > CM3_TARGET=SOLgnu > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSSERVER=birch.elegosoft.com > CM3CVSSERVER=birch.elegosoft.com > + echo CM3CVSROOT=birch.elegosoft.com:/usr/cvs > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > + echo BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSUSER= > CM3CVSUSER= > + type cvs > + true > + echo testing ssh birch.elegosoft.com.. > testing ssh birch.elegosoft.com.. > + ssh birch.elegosoft.com true > + echo ssh birch.elegosoft.com ok > ssh birch.elegosoft.com ok > + true > + [ ! -d /homes/hosking/tmp/cm3/niagara ] > + uname -s > + uname -r > TESTMACHINE=SunOS 5.10 > TTT=SOLgnu SunOS 5.10 niagara > BUILDNAME=SOLgnu SunOS 5.10 niagara release-build > + [ -z cm3 -o -z cm3 ] > BUILDNAME=SOLgnu SunOS 5.10 niagara release-build > + echo Building cm3. > Building cm3. > + echo Tinderbox Tree: "cm3" > Tinderbox Tree: "cm3" > + echo Buildname: "SOLgnu SunOS 5.10 niagara release-build" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > + echo > > + date +%Y%m%d-%H%M%S > NAME=build-cm3-20090726-063007 > + date +%s > STARTTIME=1248604207 > BUILDDIR_ROOT=/tmp > + mktemp -d /tmp/build-cm3-20090726-063007-XXXXXX > BUILDDIR_BASE=/tmp/build-cm3-20090726-063007-yIa4JX > BUILDDIR=/tmp/build-cm3-20090726-063007-yIa4JX/build > LOG=/tmp/build-cm3-20090726-063007-yIa4JX/log.txt > T=/tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + mkdir /tmp/build-cm3-20090726-063007-yIa4JX/build > + [ ! -d /tmp/build-cm3-20090726-063007-yIa4JX/build ] > + echo creating log file /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > creating log file /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + touch /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + [ ! -w /tmp/build-cm3-20090726-063007-yIa4JX/log.txt ] > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo > > + echo --- > --- > + echo > > + echo checkout, compile and test of cm3 ... > checkout, compile and test of cm3 ... > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 06:30:07 -- checkout in progress. > 2009.07.26 06:30:07 -- checkout in progress. > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248604207 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [start checkout 2009.07.26 06:30:09] > [start checkout 2009.07.26 06:30:09] > + echo cd /tmp/build-cm3-20090726-063007-yIa4JX/build > cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + do_checkout > CHECKOUT_RETURN=0 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo cvs return value: 0 > + date +%Y.%m.%d %H:%M:%S > cvs return value: 0 > + echo [end checkout 2009.07.26 06:45:02] > [end checkout 2009.07.26 06:45:02] > + echo CHECKOUT_RETURN = 0 > CHECKOUT_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248605102 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo -- > -- > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 06:45:12 -- compile in progress. > 2009.07.26 06:45:12 -- compile in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start compile 2009.07.26 06:45:12] > [start compile 2009.07.26 06:45:12] > + do_compile > COMPILE_RETURN=0 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo compile return value: 0 > compile return value: 0 > + date +%Y.%m.%d %H:%M:%S > + echo [end compile 2009.07.26 08:24:29] > [end compile 2009.07.26 08:24:29] > + echo COMPILE_RETURN = 0 > COMPILE_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248611069 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 08:24:34 -- tests in progress. > 2009.07.26 08:24:34 -- tests in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start run-tests 2009.07.26 08:24:34] > [start run-tests 2009.07.26 08:24:34] > + echo cd /tmp/build-cm3-20090726-063007-yIa4JX/build > cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + do_tests > TESTS_RETURN=511 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [end run-tests 2009.07.26 10:39:00] > [end run-tests 2009.07.26 10:39:00] > + echo TESTS_RETURN = 511 > TESTS_RETURN = 511 > + [ 511 != 0 ] > + + echotee *** TESTS FAILED-a > /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > *** TESTS FAILED > + mail_buildlog test_failed > + [ -z test_failed ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > test_failed 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=test_failed > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > test_failed -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248619141 > + echo tinderbox: status: test_failed > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + + catssh /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temptinderbox.elego.de > sudo -u tinderbox /usr/local/tinderbox/tinderbox-cgi/ > processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + cleanup > + echo removing build tree /tmp/build-cm3-20090726-063007-yIa4JX ... > removing build tree /tmp/build-cm3-20090726-063007-yIa4JX ... > + cd /tmp > + rm -rf /tmp/build-cm3-20090726-063007-yIa4JX > + do_cleanup > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > + exit 1 > + trap cleanup 1 2 3 6 > + [ -z cm3.build ] > + . cm3.build > PROJECT=cm3 > TREENAME=cm3 > BUILD_REL=lastok > BUILD_REL_NAME=lastok > REGRESSION_SCRIPTS_DIR=regression-scripts > + [ lastok = rel ] > + hostname > + [ -f ~/cm3/niagara.cs.purdue.edu.conf ] > CVSROOT=:ext:modula3.elegosoft.com:/usr/cvs > + cvs -d :ext:modula3.elegosoft.com:/usr/cvs checkout -A -d > regression-scripts cm3/scripts/regression/defs.sh > + test -r regression-scripts/defs.sh > + . regression-scripts/defs.sh > + sed -e s/\..*// > + hostname > TESTHOSTNAME=niagara > HTMP=/homes/hosking/tmp/cm3/niagara > + tr+ date-d -u\n +%Y-%m-%d-%H-%M-%S > > DS=2009-07-26-14-41-31 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > COVERSION=-P -r release_branch_cm3_5_8 > LASTREL=5.4.0 > INSTBASE=/homes/hosking/work/cm3-inst/niagara > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + test x != x > CM3CVSUSER_AT= > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > WWWSERVER=birch.elegosoft.com > RLOG=/homes/hosking/tmp/cm3/niagara/cm3-rlog-2009-07-26-14-41-31 > CM3_NKEEP=7 > + uname > UNAME=SunOS > + uname -m > UNAMEM=sun4v > TMP=/tmp > TMPDIR=/tmp > + [ ! -d /tmp ] > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > M3TOUT=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-14-41-31.stdout > M3TERR=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-14-41-31.stderr > CM3_VERSION=* > CM3_SNAPSHOT=/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu- > *-2009-07-26-14-41-31.tgz > HTML_REPORT=/tmp/cm3-pkg-report-SOLgnu-2009-07-26-14-41-31.html > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_LOC=/homes/hosking/work > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_URL=http://modula3.elegosoft.com/cm3 > + echo TESTHOSTNAME=niagara > TESTHOSTNAME=niagara > + echo WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > + echo LASTREL=5.4.0 > LASTREL=5.4.0 > + echo INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > + echo INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > + echo INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > + echo INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + echo CM3_OSTYPE=POSIX > CM3_OSTYPE=POSIX > + echo CM3_TARGET=SOLgnu > CM3_TARGET=SOLgnu > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSSERVER=birch.elegosoft.com > CM3CVSSERVER=birch.elegosoft.com > + echo CM3CVSROOT=birch.elegosoft.com:/usr/cvs > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > + echo BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSUSER= > CM3CVSUSER= > + type cvs > + true > + echo testing ssh birch.elegosoft.com.. > testing ssh birch.elegosoft.com.. > + ssh birch.elegosoft.com true > + echo ssh birch.elegosoft.com ok > ssh birch.elegosoft.com ok > + true > + [ ! -d /homes/hosking/tmp/cm3/niagara ] > + uname -s > + uname -r > TESTMACHINE=SunOS 5.10 > TTT=SOLgnu SunOS 5.10 niagara > BUILDNAME=SOLgnu SunOS 5.10 niagara lastok-build > + [ -z cm3 -o -z cm3 ] > BUILDNAME=SOLgnu SunOS 5.10 niagara lastok-build > + echo Building cm3. > Building cm3. > + echo Tinderbox Tree: "cm3" > Tinderbox Tree: "cm3" > + echo Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > + echo > > + date +%Y%m%d-%H%M%S > NAME=build-cm3-20090726-104133 > + date +%s > STARTTIME=1248619293 > BUILDDIR_ROOT=/tmp > + mktemp -d /tmp/build-cm3-20090726-104133-XXXXXX > BUILDDIR_BASE=/tmp/build-cm3-20090726-104133-R0aGhi > BUILDDIR=/tmp/build-cm3-20090726-104133-R0aGhi/build > LOG=/tmp/build-cm3-20090726-104133-R0aGhi/log.txt > T=/tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + mkdir /tmp/build-cm3-20090726-104133-R0aGhi/build > + [ ! -d /tmp/build-cm3-20090726-104133-R0aGhi/build ] > + echo creating log file /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > creating log file /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + touch /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + [ ! -w /tmp/build-cm3-20090726-104133-R0aGhi/log.txt ] > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo > > + echo --- > --- > + echo > > + echo checkout, compile and test of cm3 ... > checkout, compile and test of cm3 ... > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 10:41:34 -- checkout in progress. > 2009.07.26 10:41:34 -- checkout in progress. > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248619294 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [start checkout 2009.07.26 10:41:36] > [start checkout 2009.07.26 10:41:36] > + echo cd /tmp/build-cm3-20090726-104133-R0aGhi/build > cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + do_checkout > CHECKOUT_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a + /tmp/build-cm3-20090726-104133-R0aGhi/log.txtecho > cvs return value: 0 > + date +%Y.%m.%d %H:%M:%S > cvs return value: 0 > + echo [end checkout 2009.07.26 10:56:34] > [end checkout 2009.07.26 10:56:34] > + echo CHECKOUT_RETURN = 0 > CHECKOUT_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248620194 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp+ ssh > tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo -- > -- > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 10:56:36 -- compile in progress. > 2009.07.26 10:56:36 -- compile in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start compile 2009.07.26 10:56:36] > [start compile 2009.07.26 10:56:36] > + do_compile > COMPILE_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo compile return value: 0 > compile return value: 0 > + date +%Y.%m.%d %H:%M:%S > + echo [end compile 2009.07.26 11:54:10] > [end compile 2009.07.26 11:54:10] > + echo COMPILE_RETURN = 0 > COMPILE_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248623650 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp+ ssh > tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 11:54:14 -- tests in progress. > 2009.07.26 11:54:14 -- tests in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start run-tests 2009.07.26 11:54:14] > [start run-tests 2009.07.26 11:54:14] > + echo cd /tmp/build-cm3-20090726-104133-R0aGhi/build > cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + do_tests > TESTS_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [end run-tests 2009.07.26 11:54:14] > [end run-tests 2009.07.26 11:54:14] > + echo TESTS_RETURN = 0 > TESTS_RETURN = 0 > + [ 0 != 0 ] > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 11:54:14 -- checkout, compile and test run done. > 2009.07.26 11:54:14 -- checkout, compile and test run done. > + echo > > + echo --- > --- > + echo > > + mail_buildlog success > + [ -z success ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > success 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=success > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > success -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248623654 > + echo tinderbox: status: success > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp + > ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + cleanup > + echo removing build tree /tmp/build-cm3-20090726-104133-R0aGhi ... > removing build tree /tmp/build-cm3-20090726-104133-R0aGhi ... > + cd /tmp > + rm -rf /tmp/build-cm3-20090726-104133-R0aGhi > + do_cleanup > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > + echo done. > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 26 20:03:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:03:30 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> Message-ID: The error is coming from the server. Nothing in the CVS tree validates timenow or prints this error. # function used to send results to a tinderbox server. # per default it is empty so the build-log will just be output to stdout. tinderbox_mailer() { true # needed if function is empty without this... # to report to the elego tinderbox host, check README and uncomment this: #cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox \ #/usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" } It is that /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi. Whether you/we started feeding it different data somehow I don't know. However I don't have GNU date so I made it work with whatever is the Solaris default. I'm inclined to move on, but I agree it is not understood. Maybe put in which date type data before the runs? - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 13:48:35 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > I have not changed my tinderbox install on niagara for over a year and > it suddenly stopped working so the problem must be with some recent > commit. Note that I installed the GNU binutils way back when (over a > year ago) so that things would work with 'date +%s'. > > Sent from my iPhone > > On Jul 26, 2009, at 6:07 AM, Jay K wrote: > >> >> I'm running Tinderbox on SOLgnu now. >> It fails with that error without a change and gets past the first >> email if I change the date commands. >> The first cvs checkout eventually failed, trying again.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>> Date: Sun, 26 Jul 2009 03:09:59 +0000 >>> >>> >>> Tony reverted it. I'm bringing my Solaris/sparc machine up to date >>> and will try running Tinderbox. >>> I will likely try with plain date and see what happens there and >>> otherwise. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 25 Jul 2009 22:00:15 +0200 >>>> From: wagner at elegosoft.com >>>> To: hosking at cs.purdue.edu >>>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> Quoting Tony Hosking : >>>> >>>>> I've not changed anything on my side. >>>> >>>> I don't understand why I missed that: >>>> >>>> revision 1.13 >>>> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >>>> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >>>> let's just try plain date, based on the choices in the error message >>>> ---------------------------- >>>> >>>> But you seem to have fixed it already: >>>> >>>> revision 1.14 >>>> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >>>> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >>>> Revert to what used to work. >>>> >>>> Strange that it didn't show up in my first diff. >>>> >>>> Olaf >>>> >>>> >>>>> >>>>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>>>> >>>>>> I don't see how that will help us... It worked for Tony for over >>>>>> a year, and nothing obvious has changed. Or did something change >>>>>> on >>>>>> your side, Tony (system upgrade, path setting, ...)? >>>>>> >>>>>> It's not good to introduce arbitrary changes now without >>>>>> understanding >>>>>> why it breaks. >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting Jay K : >>>>>> >>>>>>> >>>>>>> Can I suggest the portable scripting language C? >>>>>>> >>>>>>> >>>>>>> -bash-3.00$ cat date.c >>>>>>> #include >>>>>>> #include >>>>>>> #include >>>>>>> int main() >>>>>>> { >>>>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>>>> return 0; >>>>>>> } >>>>>>> -bash-3.00$ cc date.c -o ./mydate >>>>>>> -bash-3.00$ ./mydate >>>>>>> 1248549753 >>>>>>> -bash-3.00$ pwd >>>>>>> /dev2/cm3/scripts >>>>>>> >>>>>>> >>>>>>> use that instead? >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>> >>>>>>>> >>>>>>>> (two occurences of that) >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>>>> >>>>>>>>> >>>>>>>>> This line: >>>>>>>>> >>>>>>>>> >>>>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>>>> >>>>>>>>> needs to more like these lines: >>>>>>>>> >>>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>>>> >>>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>>>> run done." >>>>>>>>> >>>>>>>>> >>>>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>>>> 2009.07.25 12:13:54 >>>>>>>>> >>>>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>>>> 07.25.09 12:14:33 >>>>>>>>> >>>>>>>>> -bash-3.00$ date +%s >>>>>>>>> %s >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>>>> From: wagner at elegosoft.com >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>>>> >>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>> >>>>>>>>>>> Perhaps I am confusing with the original change I made for >>>>>>>>>>> 1.10 to the >>>>>>>>>>> parameter to the "date" command. >>>>>>>>>>> >>>>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>>>> properly. It's been a long time since I've seen a sane >>>>>>>>>>> tinderbox run >>>>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>>>> >>>>>>>>>> I broke the last one yesterday with $() (fixed soon >>>>>>>>>> afterwards), but >>>>>>>>>> the one before succeeded: >>>>>>>>>> >>>>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>>>> >>>>>>>>>> I was hoping to get a green build from one of your systems >>>>>>>>>> today >>>>>>>>>> (big-endian, different architecture) to finally fix the RC2 >>>>>>>>>> tag. >>>>>>>>>> But if you cannot send your results to the tinderbox that >>>>>>>>>> will be >>>>>>>>>> difficult :-/ I really don't understand why that should have >>>>>>>>>> stopped >>>>>>>>>> working. >>>>>>>>>> >>>>>>>>>> The error below seems to be that the reported start time is >>>>>>>>>> 0, and >>>>>>>>>> that cannot be according to the source. Could you set -x at >>>>>>>>>> the start >>>>>>>>>> of the tinderbox script and try again? >>>>>>>>>> >>>>>>>>>> Jay, can you think of anything you have changed that may >>>>>>>>>> cause Tony's >>>>>>>>>> problem? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>>> -- Tony (not mobile) >>>>>>>>>> :-) >>>>>>>>>> >>>>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>>>> >>>>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>>>> >>>>>>>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>>>>>>> ago. Can >>>>>>>>>>>>> someone restore? >>>>>>>>>>>> >>>>>>>>>>>> Hi Tony, >>>>>>>>>>>> >>>>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>>> *************** >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>>>> date 'date +%s'" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: >>>>>>>>>>>> $STARTTIME >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>>>> >>>>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>>>> >>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>> Jul-09 >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>>> *************** >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>>>> *************** >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did >>>>>>>>>>>> you change >>>>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>> >>>>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>>>> >>>>>>>>>>>>>> produced the following output: >>>>>>>>>>>>>> >>>>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>>>> >>>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>>>>>>> log.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: >>>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>>> clock >>>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>>>>>>> minutes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023- >>>>>>>>>>>>>> tVaq2V ... >>>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>>> *.tgz >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>>>> >>>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>>>>>>> log.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: >>>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>>> clock >>>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032- >>>>>>>>>>>>>> xba4dW ... >>>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>>> *.tgz >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>>>> 45 86 95 >>>>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>>>> Sitz: Berlin >>>>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>>>> IdNr: >>>>>>>>>>>> DE163214194 >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>>> 23 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wag >>>>>>>>>> ner | Sitz: Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>> IdNr: DE163214194 >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Si >>>>>> tz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> From jay.krell at cornell.edu Sun Jul 26 20:07:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:07:54 +0000 Subject: [M3devel] OpenGL on Darwin 10.4 x86 (not MacOSX)? Message-ID: Anyone gotten OpenGL working in Darwin 10.4 x86? I don't mean MacOSX. The stripped down Darwin thing. I had a heck of a time getting X libraries on the machine. I had to upgrade Python. And X has been broken into a bunch of separate pieces. And Xaw installs kind of wrong -- Xaw7.dylib, Xaw6.dylib, and Xaw.so -- .so! I changed it around to look like my PPC_LINUX machine to get past that.. Anyway, I have libGL but not some others..tried building Mesa and SGI glx. I think I'll give up. Make the system check for SYSTEM_LIBS/LIBORDER, skip packages, and not build distributions on this system. Or am I missing smoething?? I did search the web some. Haven't asked the X/Mesa people. Maybe Fink is the way? But the result won't by default be compatible with Mac OSX. - Jay From hosking at cs.purdue.edu Sun Jul 26 20:13:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:13:09 -0400 Subject: [M3devel] libz in Tinderbox? In-Reply-To: References: Message-ID: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> What needs libz? I think it is already installed but will need to log on when able to to find where it is installed. Sent from my iPhone On Jul 26, 2009, at 1:16 PM, Jay K wrote: > > Tony can you install libz? Or should we import it? Or should we > maybe probe for $HOME/lib/libz.a or somewhere else? > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 > > "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- > tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake > runtime error: file libz.a not found in /usr/lib /usr/local/lib / > lib /usr/contrib/lib /opt/lib > 22072 > > > There is also: > > Must be attached to terminal for ?am I? option > 49575 + [ niagara = birch.elegosoft.com -a = m3 ] > 49576 ./tinderbox-build.sh: test: argument expected > 49577 r4=1 > 49578 + expr 0 + 0 + 255 + 255 + 1 > 49579 + return 511 > 49580 + date +%Y.%m.%d %H:%M:%S > 49581 + echo [end run-tests 2009.07.26 10:39:00] > 49582 [end run-tests 2009.07.26 10:39:00] > 49583 *** TESTS FAILED > > > - Jay From jay.krell at cornell.edu Sun Jul 26 20:28:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:28:06 +0000 Subject: [M3devel] libz in Tinderbox? In-Reply-To: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> References: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> Message-ID: cvsup. >> "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- >> tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 14:13:09 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] libz in Tinderbox? > > What needs libz? I think it is already installed but will need to log > on when able to to find where it is installed. > > Sent from my iPhone > > On Jul 26, 2009, at 1:16 PM, Jay K wrote: > >> >> Tony can you install libz? Or should we import it? Or should we >> maybe probe for $HOME/lib/libz.a or somewhere else? >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 >> >> "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- >> tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake >> runtime error: file libz.a not found in /usr/lib /usr/local/lib / >> lib /usr/contrib/lib /opt/lib >> 22072 >> >> >> There is also: >> >> Must be attached to terminal for ?am I? option >> 49575 + [ niagara = birch.elegosoft.com -a = m3 ] >> 49576 ./tinderbox-build.sh: test: argument expected >> 49577 r4=1 >> 49578 + expr 0 + 0 + 255 + 255 + 1 >> 49579 + return 511 >> 49580 + date +%Y.%m.%d %H:%M:%S >> 49581 + echo [end run-tests 2009.07.26 10:39:00] >> 49582 [end run-tests 2009.07.26 10:39:00] >> 49583 *** TESTS FAILED >> >> >> - Jay From jay.krell at cornell.edu Sun Jul 26 20:29:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:29:57 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: I can try that. It is a null pointer though I believe. interesting..?? On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, showthread all fail to come up. showheap comes up but doesn't show anything. I've tried some of these in the past and they worked better, though I didn't use them for anything. Maybe just a slow machine? And I'm too impatient? Yes, but I don't think that's the problem. xterm comes right up. As does the empty showheap window. Could be a wierd X server too, granted (Xming). I can try Cygwin/X and I was thinking of buying a commercial one (just for this few minutes of testing per month..) If I don't set DISPLAY ..most still hang, except showthread. Specifically showthread fails, but the others still seem to hang. $ unset DISPLAY $ ./showthread *** *** runtime error: *** Exception "TrestleComm.Failure" not in RAISES list *** file "../src/vbt/TrestleClass.m3", line 33 *** Abort trap (core dumped) I'm not sure that's how it should fail, but failure is expected. I think I've seen the failure mode vary too, but again, failure is expected there. So like we aren't even getting to XOpenDisplay. Hey, not much to debug.. perhaps.. Here is Cube hung. Again this is OpenBSD, not the most mature platform from the Modula-3 point of view. Though imho the platforms are all highly similar. $ gdb ./Cube GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.5"... (gdb) run Starting program: /home/jay/cm3/bin/Cube ? Program received signal SIGINT, Interrupt. -- I hit control-c --- 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) info threads 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched (scp=Cannot access memory at address 0x37b3 ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 (gdb) thread 5 bt A syntax error in expression, near `bt'. (gdb) thread 5 apply bt A syntax error in expression, near `apply bt'. (gdb) thread apply 5 bt Thread 5 (process 3778, thread 0x84901400): #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 Cannot access memory at address 0x37ab #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 4 bt Thread 4 (process 3778, thread 0x84901000): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x849010b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, mutex=0x8afb09e0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) at ../src/vbt/VBTRep.m3:439 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591380) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 3 bt Thread 3 (process 3778, thread 0x8182e800): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182e8b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, mutex=0x20e900dc, abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431 #3 0x00e955a7 in _thread_gc (arg=0x0) at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 #4 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #5 0x0000002b in ?? () #6 0x00000000 in ?? () #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 2 bt Thread 2 (process 3778, thread 0x8182ec00): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182ecb0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, mutex=0x8afb0a50) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) at ../src/vtext/VTView.m3:111 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591980) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 1 bt Thread 1 (process 3778, thread 0x8182e400): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182e4b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, mutex=0x8afb0b20) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) at ../src/lego/FileBrowserVBT.m3:241 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591500) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 0 bt warning: Unknown thread 0. (gdb) I should debug this more but not now. And we should be sure to try these on other platforms, see if the hangs occur. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 13:57:07 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Stack overflow? > > And yes, I have seen deep recursions like that. What happens if you > use a deeper stack? > > Sent from my iPhone > > On Jul 26, 2009, at 8:48 AM, Jay K wrote: > >> >> Ok here is the formsedit crash. >> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >> PPC_LINUX. >> I can try those again. >> >> >> It doesn't happen every time, but some large fraction, like maybe >> half. >> I changed the SIGsEGV to an assertion failure. >> >> >> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >> -bash-3.00$ ./formsedit >> >> *** >> *** runtime error: >> *** failed. >> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >> *** >> Abort (core dumped) >> >> You can't debug it live because you keep getting interrupted by sig >> usr2. >> >> -bash-3.00$ dbx formsedit core >> >> t at 1 (l at 1) terminated by signal KILL (Killed) >> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >> 0xfe3c00a4 >> >> These statements from the debugger about main/AddUnit don't make >> sense to me. >> >> Current function is main >> 13 RTLinker__AddUnit (FormsEdit_M3); >> >> (dbx) where >> current thread: t at 1 >> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 >> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xfe4680b8 >> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >> 0xfe467ca0 >> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >> 0xfefa5adc >> >> Does the code really recurse like this? >> >> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >> 0xffbf9ca0, 0xfe4a5d >> 00, 0xfef48180), at 0xfef48520 >> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >> 0xff000000, 0x0, 0x0 >> ), at 0xff046ea4 >> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >> 0xffbf9e48, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >> 0xffbf9f18, 0 >> x0, 0xff0437d8), at 0xff043864 >> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >> 0xffbfa0a8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >> 0xffbfa238, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >> 0xffbfa3c8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >> 0xffbfa558, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >> 0xffbfa6e8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >> 0xffbfa878, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >> 0xffbfaa08, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >> 0xffbfab98, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >> 0xffbfad28, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >> 0xffbfaeb8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >> 0xffbfb048, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >> 0xffbfb1d8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >> 0xffbfb368, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >> 0xffbfb4f8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >> 0xffbfb688, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >> 0xffbfb818, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >> 0xffbfb9a8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >> 0xffbfbb38, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >> 0xffbfbcc8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >> 0xffbfbe58, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >> 0xffbfbfe8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >> 0xffbfc178, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >> 0xffbfc308, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >> 0xffbfc498, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >> 0xfe1b2000, 0x6b170 >> , 0x0), at 0xff046ea4 >> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >> 0xff000000, >> 0x0, 0x0), at 0xff191d20 >> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b27 >> 0, 0x0), at 0xfefb6a38 >> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >> 0xfe1b2000, >> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b290, 0x0), at 0xfefbc9f4 >> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b2b >> 0, 0x0), at 0xfefb6a38 >> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >> 0xfe1b2000, >> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b2d0, 0x0), at 0xfefbc9f4 >> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6af7 >> 0, 0x0), at 0xfefb6a38 >> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >> 0xff000000, >> 0x0, 0x0), at 0xfefbc9f4 >> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b33 >> 0, 0x0), at 0xfefb6a38 >> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b698, 0x0), at 0xfefbc9f4 >> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >> 0xfe1b2000, 0x6b69 >> 8, 0x0), at 0xfefbc9f4 >> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >> 0xfe1b2000, 0xf >> e4a5d00, 0x0), at 0xfefeb348 >> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b6b8, 0x0), at 0xfefbc9f4 >> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b7f >> 8, 0x0), at 0xfefb6a38 >> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b858, 0x0), at 0xfefbc9f4 >> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >> 0x0, 0x0), at >> 0xfefb6a38 >> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b858, 0x0), at 0xfefbc9f4 >> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >> 0xff000000, 0x0 >> , 0x0), at 0xff18d2ec >> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b87 >> 8, 0x0), at 0xfefb6a38 >> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b898, 0x0), at 0xfefbc9f4 >> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >> 0xfe1b2000, 0x6b89 >> 8, 0x0), at 0xfefbc9f4 >> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >> 0xfe1b2000, 0x6 >> b8b8, 0x0), at 0xfefeb348 >> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >> 0x20, 0xffbfd >> b20), at 0xfefb6a38 >> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >> 0xfe1b2000, >> 0x6b8b8, 0x0), at 0xfefbc9f4 >> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xff01f884 >> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b8d8, 0x0), at 0xfefbc9f4 >> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xff19e338 >> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x60338, 0x0), at 0xfefbc9f4 >> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4a5d >> 00, 0x0), at 0xfeff6db4 >> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >> 0xfe1b2000 >> , 0x6e5a0, 0x0), at 0xfefbc9f4 >> (dbx) >> (dbx) threads >>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >> ___nanosleep >> () >> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >> in __lwp_pa >> rk() >> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >> ___nanosleep >> () >> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >> in __lwp_pa >> rk() >> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >> in __lwp_pa >> rk() >> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >> in __lwp_pa >> rk() >> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >> __lwp_kill( >> ) >> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >> in __lwp_pa >> rk() >> (dbx) >> >> >> The crashing thread: >> >> (dbx) thread t at 27 >> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >> 0xfe3c11f4 >> (dbx) where >> current thread: t at 27 >> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >> 0xfe35fdd8 >> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >> 0xfe33fff8 >> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >> 0xfe46255c >> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >> 0xfe4529c8 >> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >> 0xfddf0900), at 0x >> fe44f2e4 >> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >> 0xfe4b4d90, 0xff2 >> 50434), at 0xfe44ee5c >> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >> 0x100000), >> at 0xfe44fa0c >> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >> ), >> at 0xfe44f590 >> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >> 0xfffffff8, 0x0, >> 0xfdc53131), at 0xfe44f44c >> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >> 0x0), at 0xfe46 >> 470c >> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >> ), >> at 0xfe44f680 >> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >> 0xfffffff8, 0x0, >> 0xfdc53661), at 0xfe44f44c >> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >> 0x0, 0xfdc538 >> e1), at 0xfe46470c >> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >> 0xfdc53a40, 0xfdc539 >> 2c, 0xfdc53928), at 0xfe42ffe0 >> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >> 0xfdc53a40), a >> t 0xff141d64 >> >> (too many frames for an assertion failure imho!) >> >> >> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >> 0x1000, 0x0, >> 0x0), at 0xff13dda4 >> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >> 0xff000000, 0x0, >> 0x0), at 0xff13d9e8 >> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >> 0xfddf0800, >> 0x69da0, 0x0), at 0xff140730 >> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >> 0xff000000, 0xff00000 >> 0, 0x0, 0x1), at 0xff1407d0 >> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >> 0xfdd221bc), a >> t 0xfefb8f04 >> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >> 0xfefc5170 >> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >> 0xfddf0800, 0x90 >> 410, 0x0), at 0xfefc45a8 >> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >> 0xfefc4674 >> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >> 0xfe46bc00 >> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >> 0xfe46b740, 0x1) >> , at 0xfe46b790 >> (dbx) >> >> >> - Jay From hosking at cs.purdue.edu Sun Jul 26 20:34:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:34:02 -0400 Subject: [M3devel] libz in Tinderbox? In-Reply-To: References: Message-ID: Looks like we have it in /opt/csw/lib/ Sent from my iPhone On Jul 26, 2009, at 1:16 PM, Jay K wrote: > > Tony can you install libz? Or should we import it? Or should we > maybe probe for $HOME/lib/libz.a or somewhere else? > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 > > "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- > tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake > runtime error: file libz.a not found in /usr/lib /usr/local/lib / > lib /usr/contrib/lib /opt/lib > 22072 > > > There is also: > > Must be attached to terminal for ?am I? option > 49575 + [ niagara = birch.elegosoft.com -a = m3 ] > 49576 ./tinderbox-build.sh: test: argument expected > 49577 r4=1 > 49578 + expr 0 + 0 + 255 + 255 + 1 > 49579 + return 511 > 49580 + date +%Y.%m.%d %H:%M:%S > 49581 + echo [end run-tests 2009.07.26 10:39:00] > 49582 [end run-tests 2009.07.26 10:39:00] > 49583 *** TESTS FAILED > > > - Jay From hosking at cs.purdue.edu Sun Jul 26 20:40:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:40:57 -0400 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> Message-ID: <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> Why are we building the X client libs? Xcode should install them? Sent from my iPhone On Jul 26, 2009, at 1:57 PM, Jay K wrote: > From jay.krell at cornell.edu Sun Jul 26 20:46:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:46:04 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> Message-ID: This is just me trying to get my x86 Darwin 10.4 system able to build the Modula-3 gui stuff. Not MacOSX, but Darwin. I don't believe you can do anything at with Xcode on this. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 14:40:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Tinderbox/Hudson > > Why are we building the X client libs? > Xcode should install them? > > Sent from my iPhone > > On Jul 26, 2009, at 1:57 PM, Jay K wrote: > >> From jay.krell at cornell.edu Sun Jul 26 22:43:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 20:43:03 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: Larger stack didn't seem to help. I used export STACKSIZE=32768 and ulimit shownew/showthread come up ok on this platform, OpenBSD/x86 doesn't represent all of them. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] the formsedit crash > Date: Sun, 26 Jul 2009 18:29:57 +0000 > > > I can try that. > > > It is a null pointer though I believe. > > > interesting..?? > > > On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, showthread all fail to come up. > showheap comes up but doesn't show anything. > I've tried some of these in the past and they worked better, though I didn't use them for anything. > > > Maybe just a slow machine? > And I'm too impatient? Yes, but I don't think that's the problem. > > > xterm comes right up. > As does the empty showheap window. > > > Could be a wierd X server too, granted (Xming). > I can try Cygwin/X and I was thinking of buying a commercial one (just for > this few minutes of testing per month..) > > > If I don't set DISPLAY ..most still hang, except showthread. > Specifically showthread fails, but the others still seem to hang. > > > $ unset DISPLAY > $ ./showthread > > *** > *** runtime error: > *** Exception "TrestleComm.Failure" not in RAISES list > *** file "../src/vbt/TrestleClass.m3", line 33 > *** > Abort trap (core dumped) > > > I'm not sure that's how it should fail, but failure is expected. > I think I've seen the failure mode vary too, but again, failure is expected there. > > > So like we aren't even getting to XOpenDisplay. > Hey, not much to debug.. perhaps.. > > > Here is Cube hung. > Again this is OpenBSD, not the most mature platform from the Modula-3 point of view. > Though imho the platforms are all highly similar. > > > $ gdb ./Cube > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) run > Starting program: /home/jay/cm3/bin/Cube > ? > Program received signal SIGINT, Interrupt. -- I hit control-c --- > 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) info threads > 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched (scp=Cannot > access memory at address 0x37b3 > ) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 > 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > (gdb) thread 5 bt > A syntax error in expression, near `bt'. > (gdb) thread 5 apply bt > A syntax error in expression, near `apply bt'. > (gdb) thread apply 5 bt > Thread 5 (process 3778, thread 0x84901400): > #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 > ) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 > Cannot access memory at address 0x37ab > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 4 bt > Thread 4 (process 3778, thread 0x84901000): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x849010b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, mutex=0x8afb09e0) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, > M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, > M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) > at ../src/vbt/VBTRep.m3:439 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591380) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 3 bt > Thread 3 (process 3778, thread 0x8182e800): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182e8b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, mutex=0x20e900dc, > abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431 > #3 0x00e955a7 in _thread_gc (arg=0x0) > at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 > #4 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #5 0x0000002b in ?? () > #6 0x00000000 in ?? () > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 2 bt > Thread 2 (process 3778, thread 0x8182ec00): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182ecb0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, mutex=0x8afb0a50) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, > M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, > M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) > at ../src/vtext/VTView.m3:111 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591980) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 1 bt > Thread 1 (process 3778, thread 0x8182e400): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182e4b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, mutex=0x8afb0b20) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, > M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, > M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) > at ../src/lego/FileBrowserVBT.m3:241 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591500) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 0 bt > warning: Unknown thread 0. > (gdb) > > I should debug this more but not now. > And we should be sure to try these on other platforms, see if the hangs occur. > > - Jay > > > > > > > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 26 Jul 2009 13:57:07 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> Stack overflow? >> >> And yes, I have seen deep recursions like that. What happens if you >> use a deeper stack? >> >> Sent from my iPhone >> >> On Jul 26, 2009, at 8:48 AM, Jay K wrote: >> >>> >>> Ok here is the formsedit crash. >>> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >>> PPC_LINUX. >>> I can try those again. >>> >>> >>> It doesn't happen every time, but some large fraction, like maybe >>> half. >>> I changed the SIGsEGV to an assertion failure. >>> >>> >>> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >>> -bash-3.00$ ./formsedit >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >>> *** >>> Abort (core dumped) >>> >>> You can't debug it live because you keep getting interrupted by sig >>> usr2. >>> >>> -bash-3.00$ dbx formsedit core >>> >>> t at 1 (l at 1) terminated by signal KILL (Killed) >>> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >>> 0xfe3c00a4 >>> >>> These statements from the debugger about main/AddUnit don't make >>> sense to me. >>> >>> Current function is main >>> 13 RTLinker__AddUnit (FormsEdit_M3); >>> >>> (dbx) where >>> current thread: t at 1 >>> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >>> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 >>> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xfe4680b8 >>> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>> 0xfe467ca0 >>> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>> 0xfefa5adc >>> >>> Does the code really recurse like this? >>> >>> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >>> 0xffbf9ca0, 0xfe4a5d >>> 00, 0xfef48180), at 0xfef48520 >>> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >>> 0xff000000, 0x0, 0x0 >>> ), at 0xff046ea4 >>> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >>> 0xffbf9e48, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >>> 0xffbf9f18, 0 >>> x0, 0xff0437d8), at 0xff043864 >>> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >>> 0xffbfa0a8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >>> 0xffbfa238, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >>> 0xffbfa3c8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >>> 0xffbfa558, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >>> 0xffbfa6e8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >>> 0xffbfa878, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >>> 0xffbfaa08, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >>> 0xffbfab98, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >>> 0xffbfad28, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >>> 0xffbfaeb8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >>> 0xffbfb048, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >>> 0xffbfb1d8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >>> 0xffbfb368, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >>> 0xffbfb4f8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >>> 0xffbfb688, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >>> 0xffbfb818, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >>> 0xffbfb9a8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >>> 0xffbfbb38, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >>> 0xffbfbcc8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >>> 0xffbfbe58, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >>> 0xffbfbfe8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >>> 0xffbfc178, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >>> 0xffbfc308, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >>> 0xffbfc498, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >>> 0xfe1b2000, 0x6b170 >>> , 0x0), at 0xff046ea4 >>> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >>> 0xff000000, >>> 0x0, 0x0), at 0xff191d20 >>> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b27 >>> 0, 0x0), at 0xfefb6a38 >>> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b290, 0x0), at 0xfefbc9f4 >>> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b2b >>> 0, 0x0), at 0xfefb6a38 >>> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b2d0, 0x0), at 0xfefbc9f4 >>> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6af7 >>> 0, 0x0), at 0xfefb6a38 >>> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >>> 0xff000000, >>> 0x0, 0x0), at 0xfefbc9f4 >>> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b33 >>> 0, 0x0), at 0xfefb6a38 >>> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b698, 0x0), at 0xfefbc9f4 >>> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >>> 0xfe1b2000, 0x6b69 >>> 8, 0x0), at 0xfefbc9f4 >>> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >>> 0xfe1b2000, 0xf >>> e4a5d00, 0x0), at 0xfefeb348 >>> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b6b8, 0x0), at 0xfefbc9f4 >>> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b7f >>> 8, 0x0), at 0xfefb6a38 >>> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b858, 0x0), at 0xfefbc9f4 >>> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >>> 0x0, 0x0), at >>> 0xfefb6a38 >>> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b858, 0x0), at 0xfefbc9f4 >>> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >>> 0xff000000, 0x0 >>> , 0x0), at 0xff18d2ec >>> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b87 >>> 8, 0x0), at 0xfefb6a38 >>> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b898, 0x0), at 0xfefbc9f4 >>> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >>> 0xfe1b2000, 0x6b89 >>> 8, 0x0), at 0xfefbc9f4 >>> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6 >>> b8b8, 0x0), at 0xfefeb348 >>> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >>> 0x20, 0xffbfd >>> b20), at 0xfefb6a38 >>> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >>> 0xfe1b2000, >>> 0x6b8b8, 0x0), at 0xfefbc9f4 >>> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xff01f884 >>> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b8d8, 0x0), at 0xfefbc9f4 >>> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xff19e338 >>> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x60338, 0x0), at 0xfefbc9f4 >>> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4a5d >>> 00, 0x0), at 0xfeff6db4 >>> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >>> 0xfe1b2000 >>> , 0x6e5a0, 0x0), at 0xfefbc9f4 >>> (dbx) >>> (dbx) threads >>>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >>> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >>> ___nanosleep >>> () >>> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >>> in __lwp_pa >>> rk() >>> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >>> ___nanosleep >>> () >>> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >>> in __lwp_pa >>> rk() >>> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >>> in __lwp_pa >>> rk() >>> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >>> in __lwp_pa >>> rk() >>> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >>> __lwp_kill( >>> ) >>> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >>> in __lwp_pa >>> rk() >>> (dbx) >>> >>> >>> The crashing thread: >>> >>> (dbx) thread t at 27 >>> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >>> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >>> 0xfe3c11f4 >>> (dbx) where >>> current thread: t at 27 >>> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >>> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >>> 0xfe35fdd8 >>> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >>> 0xfe33fff8 >>> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >>> 0xfe46255c >>> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >>> 0xfe4529c8 >>> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >>> 0xfddf0900), at 0x >>> fe44f2e4 >>> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >>> 0xfe4b4d90, 0xff2 >>> 50434), at 0xfe44ee5c >>> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >>> 0x100000), >>> at 0xfe44fa0c >>> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >>> ), >>> at 0xfe44f590 >>> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>> 0xfffffff8, 0x0, >>> 0xfdc53131), at 0xfe44f44c >>> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >>> 0x0), at 0xfe46 >>> 470c >>> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >>> ), >>> at 0xfe44f680 >>> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>> 0xfffffff8, 0x0, >>> 0xfdc53661), at 0xfe44f44c >>> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >>> 0x0, 0xfdc538 >>> e1), at 0xfe46470c >>> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >>> 0xfdc53a40, 0xfdc539 >>> 2c, 0xfdc53928), at 0xfe42ffe0 >>> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >>> 0xfdc53a40), a >>> t 0xff141d64 >>> >>> (too many frames for an assertion failure imho!) >>> >>> >>> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >>> 0x1000, 0x0, >>> 0x0), at 0xff13dda4 >>> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >>> 0xff000000, 0x0, >>> 0x0), at 0xff13d9e8 >>> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >>> 0xfddf0800, >>> 0x69da0, 0x0), at 0xff140730 >>> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >>> 0xff000000, 0xff00000 >>> 0, 0x0, 0x1), at 0xff1407d0 >>> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >>> 0xfdd221bc), a >>> t 0xfefb8f04 >>> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >>> 0xfefc5170 >>> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >>> 0xfddf0800, 0x90 >>> 410, 0x0), at 0xfefc45a8 >>> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >>> 0xfefc4674 >>> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >>> 0xfe46bc00 >>> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >>> 0xfe46b740, 0x1) >>> , at 0xfe46b790 >>> (dbx) >>> >>> >>> - Jay From wagner at elegosoft.com Sun Jul 26 23:09:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 23:09:45 +0200 Subject: [M3devel] Late news Message-ID: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> Hi again, I just browsed through the latest messages... I can barely keep up with reading everything. Tinderbox results look much better now, almost nothing is red any more. Can you make sure that you're building the branch during release engineering and not from the trunk? I think you are, if you are using the latest defs.sh and not a customized one. Solaris seems to be OK again, after the confusion of yesterday evening. I was not really aware that Tinderbox depends on a GNU date option though. We should add I386_DARWIN to the list of required platform, too, as Tony mentioned. Thanks that you're looking into the formsedit crash now. I guess I was getting a bit impatient this morning :-/ I shouldn't have taken over release engineering if I am though :-) As for setting up Hudson for release engineering: if anyone gives me remote ssh access with a separate account (preferably hudson), enough disk space and CPU power (and JDK >= 1.5), I can set up a slave server for birch remotely without any problems. I've done that several times now. It's just an offer for those who may have idling machines standing in the attic though ;-) I assume it should even work on Windows. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 00:22:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 00:22:58 +0200 Subject: [M3devel] gcc error on PPC_DARWIN Message-ID: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> compiler bootstrap on PPC_DARWIN failed with `invalid option 32': http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console Do we really require 64-bit capable tools now on all systems? Or did I make some stupid error again? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 06:09:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 04:09:02 +0000 Subject: [M3devel] gcc error on PPC_DARWIN In-Reply-To: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> References: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> Message-ID: I kind of throw in that everywhere until/unless shown that it hurts and isn't needed. Indeed it doesn't always work, not always on gcc, not always on cm3cg. I have this probe in Darwin.common now, since I was using an AMD64_DARWIN machine the other day: if not defined("SYSTEM_CC") not this part if equal(WORD_SIZE, "32BITS") SYSTEM_CC = "32" else SYSTEM_CC = "64" end % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -fPIC -m" & SYSTEM_CC local a = SYSTEM_CC & " -arch " & GccArch this part, with -arch or not local b = try_exec("@" & a & " -v 2>/dev/null") if equal(b, 0) SYSTEM_CC = a end %write("SYSTEM_CC is " & SYSTEM_CC & "\n") end if not defined("SYSTEM_LIBTOOL") readonly SYSTEM_LIBTOOL = "libtool" end which should be redundant with the -m32/64 stuff, so try just: if not defined("SYSTEM_CC") % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -fPIC" local a = SYSTEM_CC & " -arch " & GccArch local b = try_exec("@" & a & " -v 2>/dev/null") if equal(b, 0) SYSTEM_CC = a end %write("SYSTEM_CC is " & SYSTEM_CC & "\n") end if not defined("SYSTEM_LIBTOOL") readonly SYSTEM_LIBTOOL = "libtool" end I know this kind of probing is inefficient -- we do it every invocation of cm3. We could at least limit it to if there is a need to compile C or link -- like how GetM3BackFlags works now (sort of -- not probe related, but just related to bootstrapping or not). The alternative is to let users edit or have cminstall do the probe -- and have it go stale when the tools change.. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 00:22:58 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] gcc error on PPC_DARWIN > > compiler bootstrap on PPC_DARWIN failed with `invalid option 32': > http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console > > Do we really require 64-bit capable tools now on all systems? > Or did I make some stupid error again? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 06:16:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 04:16:15 +0000 Subject: [M3devel] crash in m3bundle on SPARC64_OPENBSD Message-ID: == package /dev2/cm3/m3-sys/cm3ide == +++ /cm3/bin/cm3 -build -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSI ON_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in SPARC64_OPENBSD --- ignoring ../src/m3overrides /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x134afc = NoteStackLocations + 0x2c in ../src/runtime/common/RTColl ector.m3 *** Abort trap (core dumped) new source -> compiling Buf.i3 $ cd /dev2/cm3/m3-sys/cm3ide $ rm -rf SPARC64_OPENBSD/ $ /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x134afc = NoteStackLocations + 0x2c in ../src/runtime/common/RTColl ector.m3 *** Abort trap (core dumped) $ gdb --args /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-openbsd4.3"... (gdb) run Starting program: /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk Program received signal SIGSEGV, Segmentation fault. 0x0000000000134afc in RTCollector__NoteStackLocations ( M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) at ../src/runtime/common/RTCollector.m3:525 525 WITH page = AddressToPage(fp^) DO (gdb) disas Dump of assembler code for function RTCollector__NoteStackLocations: 0x0000000000134ad0 : save %sp, -224, %sp 0x0000000000134ad4 : stx %i0, [ %fp + 0x87f ] 0x0000000000134ad8 : stx %i1, [ %fp + 0x887 ] 0x0000000000134adc : ldx [ %fp + 0x8 7f ], %g1 0x0000000000134ae0 : stx %g1, [ %fp + 0x7df ] 0x0000000000134ae4 : ldx [ %fp + 0x8 87 ], %g1 0x0000000000134ae8 : add %g1, -8, %g 1 0x0000000000134aec : stx %g1, [ %fp + 0x887 ] 0x0000000000134af0 : b %xcc, 0x134ba c 0x0000000000134af4 : nop 0x0000000000134af8 : ldx [ %fp + 0x7 df ], %g1 0x0000000000134afc : ldx [ %g1 ], %g <<< here 1 0x0000000000134b00 : mov %g1, %o0 ---Type to continue, or q to quit---q Quit (gdb) p $g1 $1 = 0 <<< null deref (gdb) bt #0 0x0000000000134afc in RTCollector__NoteStackLocations ( M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) at ../src/runtime/common/RTCollector.m3:525 #1 0x000000000015a44c in ThreadPThread__ProcessMe ( M3_CgoaiZ_me=0xd800000000000000, M3_Ad3xEV_p=0x58daebea047a3667) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #2 0x0000000000159e48 in ThreadF__ProcessStacks ( M3_Ad3xEV_p=0x10000000004d8c29) at ../src/thread/PTHREAD/ThreadPThread.m3:938 #3 0x000000000013680c in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:821 #4 0x0000000000135ee4 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:721 #5 0x0000000000135600 in RTCollector__CollectEnough ( M3_AicXUJ_allocator=56 '8') at ../src/runtime/common/RTCollector.m3:653 #6 0x000000000013986c in RTCollector__LongAlloc ( M3_Cwb5VA_dataSize=11889503016258108627, M3_Cwb5VA_dataAlignment=12754194144713243859, M3_D000bG_pool=0xc300000000000000) at ../src/runtime/common/RTCollector.m3:1438 #7 0x0000000000139644 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=0, M3_Cwb5VA_dataAlignment=0, M3_D000bG_pool=0x0) at ../src/runtime/common/RTCollector.m3:1400 #8 0x0000000000130578 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) ---Type to continue, or q to quit--- at ../src/runtime/common/RTAllocator.m3:222 #9 0x000000000012fc50 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:120 #10 0x0000000000156c8c in ThreadPThread__CreateT (M3_CgoaiZ_act=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:497 #11 0x000000000015bb5c in ThreadF__Init () at ../src/thread/PTHREAD/ThreadPThread.m3:1377 #12 0x000000000014392c in RTLinker__InitRuntime ( M3_AcxOUs_p_argc=7455543629306877523, M3_AJWxb1_p_argv=0x5f5253483d737368, M3_AJWxb1_p_envp=0x5353485f545459, M3_AJWxb1_p_instance=0x3d2f6465762f7474) at ../src/runtime/common/RTLinker.m3:59 #13 0x00000000001028e4 in main (argc=0, argv=0x0, envp=0x0) at _m3main.mc:3 It happens every time. wild guess would be that..SPARC platforms without stack walker don't work? No, SPARC32_LINUX does better. That no SPARC64 platform works? Could be. We'll see in SPARC64_SOLARIS, SPARC64_LINUX /eventually/. I'll try to let this go for now, it being SPARC64_OPENBSD.. This is also two releases behind. $ uname -a OpenBSD jay-sun2.jkhome 4.3 GENERIC#1555 sparc64 current OpenBSD release is 4.5. - Jay From jay.krell at cornell.edu Mon Jul 27 09:12:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 07:12:52 +0000 Subject: [M3devel] Late news In-Reply-To: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> References: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> Message-ID: As for setting up Hudson for release engineering: if anyone gives meremote ssh access with a separate account (preferably hudson), - Can you checkin text files to configure it? - Do you have the thing setup where it submits reports? Ie: where the master doesn't need access to the slave, or such? - All my machines are behind NAT. I think I could give you access one at a time via forwarding port 22?, and actually, I only have the server running so far on NT and one other machine. I wasn't able to get a public key from ~wagner/.ssh or ~hudson/.ssh on birch, access denied ok..I think I have something, separate mail.. - Jay ---------------------------------------- > Date: Sun, 26 Jul 2009 23:09:45 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Late news > > Hi again, > > I just browsed through the latest messages... I can barely keep up > with reading everything. > > Tinderbox results look much better now, almost nothing is red any more. > Can you make sure that you're building the branch during release > engineering and not from the trunk? I think you are, if you are using > the latest defs.sh and not a customized one. > > Solaris seems to be OK again, after the confusion of yesterday evening. > I was not really aware that Tinderbox depends on a GNU date option > though. > > We should add I386_DARWIN to the list of required platform, too, > as Tony mentioned. > > Thanks that you're looking into the formsedit crash now. > I guess I was getting a bit impatient this morning :-/ > I shouldn't have taken over release engineering if I am though :-) > > As for setting up Hudson for release engineering: if anyone gives me > remote ssh access with a separate account (preferably hudson), > enough disk space and CPU power (and JDK>= 1.5), I can set up a > slave server for birch remotely without any problems. I've done > that several times now. > It's just an offer for those who may have idling machines standing in > the attic though ;-) I assume it should even work on Windows. > > So long, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 11:16:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 09:16:48 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: >>> I've heard cvs is a cpu hog, it's one reason people switch away from >>> it (which I hope we'll do after this release..) > > > I'll have to search, initial searches failed. > > >> Not that I know... it usually sleeps while waiting for file i/o. > > > True. Load average is high on birch, 8. I don't know what this means but I thought it was was supposed to be around 1. Or is 1 times the number of processors? cvs, by me and hudson, often visible taking a lot, judging by top. Tinderbox...is causing too much heat in my apartment. After a few green runs I'll have to see about powering the machines on once a week or something for one run and then power back off. Maybe leave just one running daily or in a loop, like LINUXLIB6. Later maybe move all x86/amd64 machines to virtual machines and inherit power management of host or scheduled power off/on. - Jay From jay.krell at cornell.edu Mon Jul 27 13:28:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 11:28:54 +0000 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) Message-ID: CVS checkout and update of an entire tree seem to be extremely unreliable. It takes a while and often times out. I don't have time to do this right now, I think the cvs update/checkout should go like this: if directory doesn't exist: checkout with -l if directory does exist (it always will now actually, this if can go, except to error if it doesn't exist) cd into it upd -l various hardcoded directories, m3-sys scripts m3-ui m3-libs www doc This list need not be complete and it may contain directories that don't exist. for each directory cvs -z3 upd -dAP that directory notice that after the first one, the directory list will be correct Possibly do it like m3-sys m3-sys/m3cc m3-sys/m3gdb m3-libs m3-libs/m3core m3-libs/libm3 to breakdown some of the larger ones. and then one cvs -z3 upd -dAP at the root check return code of just that line one, if failed, wait five minutes try again, if failed, fail I plan to implement this and I'd /prefer/ to use Python. If nobody else wants it, I'll turn it off by default. Even just leaving the workspace aorund doesn't seem to solve the problem. I'd also be curious about -z1 vs. -z3. I usually use -z3. That's what some documentation recommended. - Jay From wagner at elegosoft.com Mon Jul 27 14:30:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 14:30:39 +0200 Subject: [M3devel] crash in m3bundle on SPARC64_OPENBSD In-Reply-To: References: Message-ID: <20090727143039.fp8eyulhb4ggcgkc@mail.elegosoft.com> Please put the evidence into a trac ticket. Thanks, Olaf Quoting Jay K : > > == package /dev2/cm3/m3-sys/cm3ide == > > +++ /cm3/bin/cm3 -build -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 > -DCM3_VERSI > ON_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in SPARC64_OPENBSD --- > ignoring ../src/m3overrides > /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x134afc = NoteStackLocations + 0x2c in > ../src/runtime/common/RTColl > ector.m3 > *** > Abort trap (core dumped) > new source -> compiling Buf.i3 > > $ cd /dev2/cm3/m3-sys/cm3ide > $ rm -rf SPARC64_OPENBSD/ > $ /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x134afc = NoteStackLocations + 0x2c in > ../src/runtime/common/RTColl > ector.m3 > *** > Abort trap (core dumped) > > $ gdb --args /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc64-unknown-openbsd4.3"... > (gdb) run > Starting program: /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000134afc in RTCollector__NoteStackLocations ( > M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) > at ../src/runtime/common/RTCollector.m3:525 > 525 WITH page = AddressToPage(fp^) DO > (gdb) disas > Dump of assembler code for function RTCollector__NoteStackLocations: > 0x0000000000134ad0 : save %sp, -224, %sp > 0x0000000000134ad4 : stx %i0, [ %fp + 0x87f > ] > 0x0000000000134ad8 : stx %i1, [ %fp + 0x887 > ] > 0x0000000000134adc : ldx [ %fp + 0x8 > 7f ], %g1 > 0x0000000000134ae0 : stx %g1, [ %fp > + 0x7df ] > 0x0000000000134ae4 : ldx [ %fp + 0x8 > 87 ], %g1 > 0x0000000000134ae8 : add %g1, -8, %g > 1 > 0x0000000000134aec : stx %g1, [ %fp > + 0x887 ] > 0x0000000000134af0 : b %xcc, 0x134ba > c > 0x0000000000134af4 : nop > 0x0000000000134af8 : ldx [ %fp + 0x7 > df ], %g1 > 0x0000000000134afc : ldx [ %g1 ], %g <<< here > 1 > 0x0000000000134b00 : mov %g1, %o0 > ---Type to continue, or q to quit---q > Quit > (gdb) p $g1 > $1 = 0 <<< null deref > (gdb) bt > #0 0x0000000000134afc in RTCollector__NoteStackLocations ( > M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) > at ../src/runtime/common/RTCollector.m3:525 > #1 0x000000000015a44c in ThreadPThread__ProcessMe ( > M3_CgoaiZ_me=0xd800000000000000, M3_Ad3xEV_p=0x58daebea047a3667) > at ../src/thread/PTHREAD/ThreadPThread.m3:1014 > #2 0x0000000000159e48 in ThreadF__ProcessStacks ( > M3_Ad3xEV_p=0x10000000004d8c29) > at ../src/thread/PTHREAD/ThreadPThread.m3:938 > #3 0x000000000013680c in RTCollector__CollectSomeInStateZero () > at ../src/runtime/common/RTCollector.m3:821 > #4 0x0000000000135ee4 in RTCollector__CollectSome () > at ../src/runtime/common/RTCollector.m3:721 > #5 0x0000000000135600 in RTCollector__CollectEnough ( > M3_AicXUJ_allocator=56 '8') at ../src/runtime/common/RTCollector.m3:653 > #6 0x000000000013986c in RTCollector__LongAlloc ( > M3_Cwb5VA_dataSize=11889503016258108627, > M3_Cwb5VA_dataAlignment=12754194144713243859, > M3_D000bG_pool=0xc300000000000000) > at ../src/runtime/common/RTCollector.m3:1438 > #7 0x0000000000139644 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=0, > M3_Cwb5VA_dataAlignment=0, M3_D000bG_pool=0x0) > at ../src/runtime/common/RTCollector.m3:1400 > #8 0x0000000000130578 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) > ---Type to continue, or q to quit--- > at ../src/runtime/common/RTAllocator.m3:222 > #9 0x000000000012fc50 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) > at ../src/runtime/common/RTAllocator.m3:120 > #10 0x0000000000156c8c in ThreadPThread__CreateT (M3_CgoaiZ_act=0x0) > at ../src/thread/PTHREAD/ThreadPThread.m3:497 > #11 0x000000000015bb5c in ThreadF__Init () > at ../src/thread/PTHREAD/ThreadPThread.m3:1377 > #12 0x000000000014392c in RTLinker__InitRuntime ( > M3_AcxOUs_p_argc=7455543629306877523, > M3_AJWxb1_p_argv=0x5f5253483d737368, M3_AJWxb1_p_envp=0x5353485f545459, > M3_AJWxb1_p_instance=0x3d2f6465762f7474) > at ../src/runtime/common/RTLinker.m3:59 > #13 0x00000000001028e4 in main (argc=0, argv=0x0, envp=0x0) at _m3main.mc:3 > > > It happens every time. > > > wild guess would be that..SPARC platforms without stack walker don't work? > No, SPARC32_LINUX does better. > > > That no SPARC64 platform works? Could be. > We'll see in SPARC64_SOLARIS, SPARC64_LINUX /eventually/. > > > I'll try to let this go for now, it being SPARC64_OPENBSD.. > > > This is also two releases behind. > > > $ uname -a > OpenBSD jay-sun2.jkhome 4.3 GENERIC#1555 sparc64 > > > current OpenBSD release is 4.5. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 15:19:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 15:19:56 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> Quoting Jay K : >>>> I've heard cvs is a cpu hog, it's one reason people switch away from >>>> it (which I hope we'll do after this release..) >> >> I'll have to search, initial searches failed. >> >>> Not that I know... it usually sleeps while waiting for file i/o. >> >> True. > > Load average is high on birch, 8. > I don't know what this means but I thought it was was supposed to be > around 1. No. The load average is the average number of processes competing for cpu within the last one/five/fifteen minutes. See http://en.wikipedia.org/wiki/Load_(computing) for details. In general no process will wait for CPU at all if your load average is lower than the number of processors. > Or is 1 times the number of processors? o Linux systems count not only runnable processes as the article in Wikipedia says. o Unix systems in general can handle high loads fairly well. o birch is performing a lot of services: CVS, ssh, ftp, web service, trac, mail backup, etc. So a somewhat higher load is expected. > cvs, by me and hudson, often visible taking a lot, judging by top. I really think the limiting factor are the disks, unless you are using compression and/or encryption (-z, ssh access). But that is not inherent to CVS. You will find that running other SCM systems (like ClearCase, Subversion with HTTPS/Apache access, PVCS/Dimensions, ...) will put much higher demands to your resources than simple CVS. > Tinderbox...is causing too much heat in my apartment. After a few > green runs I'll have to see about powering the machines on once a > week or something for one run and then power back off. That's understandable. > Maybe leave just one running daily or in a loop, like LINUXLIB6. > Later maybe move all x86/amd64 machines to virtual machines and > inherit power management of host or scheduled power off/on. I think we should try to obtain access to a few machines in a large data center. Perhaps we can use the HP Partner Virtualization Program. I'm not sure if we can get access for an open source project or need to make a contract as a company (Elego). We'll investigate that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 15:31:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 15:31:55 +0200 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) Message-ID: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> Quoting Jay K : > CVS checkout and update of an entire tree seem to be extremely unreliable. > It takes a while and often times out. It should not take longer than about 5 minutes, and considering the number of files and amount of data to be transferred, that's quite acceptable. > I don't have time to do this right now, I think the cvs > update/checkout should go like this: > > if directory doesn't exist: > checkout with -l > > if directory does exist (it always will now actually, this if can > go, except to error if it doesn't exist) > cd into it > upd -l various hardcoded directories, m3-sys scripts m3-ui m3-libs www doc > This list need not be complete and it may contain directories > that don't exist. > for each directory cvs -z3 upd -dAP that directory > notice that after the first one, the directory list will be correct > Possibly do it like m3-sys m3-sys/m3cc m3-sys/m3gdb m3-libs > m3-libs/m3core m3-libs/libm3 > to breakdown some of the larger ones. > and then one cvs -z3 upd -dAP at the root > check return code of just that line one, if failed, wait five > minutes try again, if failed, fail > > I plan to implement this and I'd /prefer/ to use Python. > > If nobody else wants it, I'll turn it off by default. > > Even just leaving the workspace aorund doesn't seem to solve the problem. I don't think it's a good idea. If you really want to speed it up and make it more robust, replicate the CM3 repo locally and do checkouts via the file system (much faster without ssh). You may run cvsup in a loop to get all changes quickly. If we really run out of resources on birch, we may need to set up a public r/o copy of the repository for cvs access. > I'd also be curious about -z1 vs. -z3. > I usually use -z3. That's what some documentation recommended. I think it may rather make performance worse as compression needs much CPU on birch, which may not be available under high system loads. Please remember that birch is used for other purposes by Elego than only to serve the CM3 repository. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 15:53:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 13:53:09 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> Message-ID: I am using ssh, and just -z1. 5 minutes I don't think so. It takes quite a while..maybe a minute, on a cvs -z3 upd from the root before it transfers any files. But subsequent nearby-in-time runs are faster. Some caching affects but they are surprising -- which cache? How much data is being accessed? I don't know, haven't traced it or anything. Yeah some source control is heavyweight but I think many are not. Git seems to be rapidly gaining in popularity and with that you probably hit "the server" much less. I worry "distributed source control" like Git would make sharing changes too infrequent, maybe worse than the other side too requent. I thought cvsup might be a good solution but haven't tried it yet. Only time/interest for so many new things at a time. I'll check with a friend about hosting my weirdo machines. I see the Mac has good command line control of "scheduled wake". If all my hardware had "scheduled wake" would be easy. I only first saw this feature recently on an SGI. I don't know how common it is. Ultimately an Intel Mac with scheduled sleep/wake, and starting up N virtual machines upon startup, either on a schedule or that each wait an hour, two hours, three hours, etc. before doing anything, should be able to substitute for I figure roughly 15 machines -- (Linux + OpenBSD + FreeBSD + NetBSD + Solaris + NT + Darwin) * (I386 + AMD4) + PPC_DARWIN. I had an Intel Mac but returned it and will get a "bigger" (more diskspace) soon. Heck, just run them all serially in a loop, just one heat spewing machine, should be a good setup. And then gradually try to add even more esoteric systems (Spin?). It kind of feels like cheating but also seems like a good idea. VMware has even automated the installs of some operating systems, very nice. Still that leaves PPC, SPARC, MIPS, IA64, Alpha to run on real hardware (though several of those boast virtualization features, I expect it is much harder to get up and running than the x86 virtualization products..) - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 15:19:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] tinderbox status improvements/diagnosis > > Quoting Jay K : > >>>>> I've heard cvs is a cpu hog, it's one reason people switch away from >>>>> it (which I hope we'll do after this release..) >>> >>> I'll have to search, initial searches failed. >>> >>>> Not that I know... it usually sleeps while waiting for file i/o. >>> >>> True. >> >> Load average is high on birch, 8. >> I don't know what this means but I thought it was was supposed to be >> around 1. > > No. The load average is the average number of processes competing for cpu > within the last one/five/fifteen minutes. See > http://en.wikipedia.org/wiki/Load_(computing) for details. > > In general no process will wait for CPU at all if your load average > is lower than the number of processors. > >> Or is 1 times the number of processors? > > o Linux systems count not only runnable processes as the article > in Wikipedia says. > > o Unix systems in general can handle high loads fairly well. > > o birch is performing a lot of services: CVS, ssh, ftp, web service, > trac, mail backup, etc. So a somewhat higher load is expected. > >> cvs, by me and hudson, often visible taking a lot, judging by top. > > I really think the limiting factor are the disks, unless you are > using compression and/or encryption (-z, ssh access). But that is > not inherent to CVS. > > You will find that running other SCM systems (like ClearCase, > Subversion with HTTPS/Apache access, PVCS/Dimensions, ...) will > put much higher demands to your resources than simple CVS. > >> Tinderbox...is causing too much heat in my apartment. After a few >> green runs I'll have to see about powering the machines on once a >> week or something for one run and then power back off. > > That's understandable. > >> Maybe leave just one running daily or in a loop, like LINUXLIB6. > >> Later maybe move all x86/amd64 machines to virtual machines and >> inherit power management of host or scheduled power off/on. > > I think we should try to obtain access to a few machines in a > large data center. Perhaps we can use the HP Partner Virtualization Program. > I'm not sure if we can get access for an open source project or need > to make a contract as a company (Elego). We'll investigate that. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hosking at cs.purdue.edu Mon Jul 27 15:52:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Jul 2009 09:52:46 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: Not sure if doing it that way works. Current default stack size set in ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try changing it there. On 26 Jul 2009, at 16:43, Jay K wrote: > > Larger stack didn't seem to help. > > I used export STACKSIZE=32768 > and ulimit > > shownew/showthread come up ok on this platform, OpenBSD/x86 doesn't > represent all of them. > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] the formsedit crash >> Date: Sun, 26 Jul 2009 18:29:57 +0000 >> >> >> I can try that. >> >> >> It is a null pointer though I believe. >> >> >> interesting..?? >> >> >> On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, >> showthread all fail to come up. >> showheap comes up but doesn't show anything. >> I've tried some of these in the past and they worked better, though >> I didn't use them for anything. >> >> >> Maybe just a slow machine? >> And I'm too impatient? Yes, but I don't think that's the problem. >> >> >> xterm comes right up. >> As does the empty showheap window. >> >> >> Could be a wierd X server too, granted (Xming). >> I can try Cygwin/X and I was thinking of buying a commercial one >> (just for >> this few minutes of testing per month..) >> >> >> If I don't set DISPLAY ..most still hang, except showthread. >> Specifically showthread fails, but the others still seem to hang. >> >> >> $ unset DISPLAY >> $ ./showthread >> >> *** >> *** runtime error: >> *** Exception "TrestleComm.Failure" not in RAISES list >> *** file "../src/vbt/TrestleClass.m3", line 33 >> *** >> Abort trap (core dumped) >> >> >> I'm not sure that's how it should fail, but failure is expected. >> I think I've seen the failure mode vary too, but again, failure is >> expected there. >> >> >> So like we aren't even getting to XOpenDisplay. >> Hey, not much to debug.. perhaps.. >> >> >> Here is Cube hung. >> Again this is OpenBSD, not the most mature platform from the >> Modula-3 point of view. >> Though imho the platforms are all highly similar. >> >> >> $ gdb ./Cube >> GNU gdb 6.3 >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) run >> Starting program: /home/jay/cm3/bin/Cube >> ? >> Program received signal SIGINT, Interrupt. -- I hit control-c --- >> 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) info threads >> 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched >> (scp=Cannot >> access memory at address 0x37b3 >> ) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 >> 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> (gdb) thread 5 bt >> A syntax error in expression, near `bt'. >> (gdb) thread 5 apply bt >> A syntax error in expression, near `apply bt'. >> (gdb) thread apply 5 bt >> Thread 5 (process 3778, thread 0x84901400): >> #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 >> ) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 >> Cannot access memory at address 0x37ab >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 4 bt >> Thread 4 (process 3778, thread 0x84901000): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x849010b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, >> mutex=0x8afb09e0) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, >> M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, >> M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) >> at ../src/vbt/VBTRep.m3:439 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591380) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 3 bt >> Thread 3 (process 3778, thread 0x8182e800): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182e8b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, >> mutex=0x20e900dc, >> abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/ >> uthread_cond.c:431 >> #3 0x00e955a7 in _thread_gc (arg=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 >> #4 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #5 0x0000002b in ?? () >> #6 0x00000000 in ?? () >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 2 bt >> Thread 2 (process 3778, thread 0x8182ec00): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182ecb0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, >> mutex=0x8afb0a50) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, >> M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, >> M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) >> at ../src/vtext/VTView.m3:111 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591980) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 1 bt >> Thread 1 (process 3778, thread 0x8182e400): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182e4b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, >> mutex=0x8afb0b20) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, >> M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, >> M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) >> at ../src/lego/FileBrowserVBT.m3:241 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591500) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 0 bt >> warning: Unknown thread 0. >> (gdb) >> >> I should debug this more but not now. >> And we should be sure to try these on other platforms, see if the >> hangs occur. >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 26 Jul 2009 13:57:07 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] the formsedit crash >>> >>> Stack overflow? >>> >>> And yes, I have seen deep recursions like that. What happens if you >>> use a deeper stack? >>> >>> Sent from my iPhone >>> >>> On Jul 26, 2009, at 8:48 AM, Jay K wrote: >>> >>>> >>>> Ok here is the formsedit crash. >>>> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >>>> PPC_LINUX. >>>> I can try those again. >>>> >>>> >>>> It doesn't happen every time, but some large fraction, like maybe >>>> half. >>>> I changed the SIGsEGV to an assertion failure. >>>> >>>> >>>> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >>>> -bash-3.00$ ./formsedit >>>> >>>> *** >>>> *** runtime error: >>>> *** failed. >>>> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >>>> *** >>>> Abort (core dumped) >>>> >>>> You can't debug it live because you keep getting interrupted by sig >>>> usr2. >>>> >>>> -bash-3.00$ dbx formsedit core >>>> >>>> t at 1 (l at 1) terminated by signal KILL (Killed) >>>> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >>>> 0xfe3c00a4 >>>> >>>> These statements from the debugger about main/AddUnit don't make >>>> sense to me. >>>> >>>> Current function is main >>>> 13 RTLinker__AddUnit (FormsEdit_M3); >>>> >>>> (dbx) where >>>> current thread: t at 1 >>>> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >>>> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at >>>> 0xfe3b85e4 >>>> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xfe4680b8 >>>> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>>> 0xfe467ca0 >>>> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>>> 0xfefa5adc >>>> >>>> Does the code really recurse like this? >>>> >>>> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >>>> 0xffbf9ca0, 0xfe4a5d >>>> 00, 0xfef48180), at 0xfef48520 >>>> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >>>> 0xff000000, 0x0, 0x0 >>>> ), at 0xff046ea4 >>>> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >>>> 0xffbf9e48, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >>>> 0xffbf9f18, 0 >>>> x0, 0xff0437d8), at 0xff043864 >>>> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >>>> 0xffbfa0a8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >>>> 0xffbfa238, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >>>> 0xffbfa3c8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >>>> 0xffbfa558, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >>>> 0xffbfa6e8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >>>> 0xffbfa878, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >>>> 0xffbfaa08, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >>>> 0xffbfab98, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >>>> 0xffbfad28, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >>>> 0xffbfaeb8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >>>> 0xffbfb048, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >>>> 0xffbfb1d8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >>>> 0xffbfb368, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >>>> 0xffbfb4f8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >>>> 0xffbfb688, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >>>> 0xffbfb818, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >>>> 0xffbfb9a8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >>>> 0xffbfbb38, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >>>> 0xffbfbcc8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >>>> 0xffbfbe58, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >>>> 0xffbfbfe8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >>>> 0xffbfc178, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >>>> 0xffbfc308, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >>>> 0xffbfc498, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >>>> 0xfe1b2000, 0x6b170 >>>> , 0x0), at 0xff046ea4 >>>> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >>>> 0xff000000, >>>> 0x0, 0x0), at 0xff191d20 >>>> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b27 >>>> 0, 0x0), at 0xfefb6a38 >>>> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>>> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b290, 0x0), at 0xfefbc9f4 >>>> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b2b >>>> 0, 0x0), at 0xfefb6a38 >>>> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>>> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b2d0, 0x0), at 0xfefbc9f4 >>>> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6af7 >>>> 0, 0x0), at 0xfefb6a38 >>>> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >>>> 0xff000000, >>>> 0x0, 0x0), at 0xfefbc9f4 >>>> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b33 >>>> 0, 0x0), at 0xfefb6a38 >>>> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b698, 0x0), at 0xfefbc9f4 >>>> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >>>> 0xfe1b2000, 0x6b69 >>>> 8, 0x0), at 0xfefbc9f4 >>>> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xf >>>> e4a5d00, 0x0), at 0xfefeb348 >>>> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b6b8, 0x0), at 0xfefbc9f4 >>>> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b7f >>>> 8, 0x0), at 0xfefb6a38 >>>> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b858, 0x0), at 0xfefbc9f4 >>>> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >>>> 0x0, 0x0), at >>>> 0xfefb6a38 >>>> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b858, 0x0), at 0xfefbc9f4 >>>> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >>>> 0xff000000, 0x0 >>>> , 0x0), at 0xff18d2ec >>>> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b87 >>>> 8, 0x0), at 0xfefb6a38 >>>> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b898, 0x0), at 0xfefbc9f4 >>>> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >>>> 0xfe1b2000, 0x6b89 >>>> 8, 0x0), at 0xfefbc9f4 >>>> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6 >>>> b8b8, 0x0), at 0xfefeb348 >>>> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >>>> 0x20, 0xffbfd >>>> b20), at 0xfefb6a38 >>>> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >>>> 0xfe1b2000, >>>> 0x6b8b8, 0x0), at 0xfefbc9f4 >>>> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xff01f884 >>>> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b8d8, 0x0), at 0xfefbc9f4 >>>> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xff19e338 >>>> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x60338, 0x0), at 0xfefbc9f4 >>>> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4a5d >>>> 00, 0x0), at 0xfeff6db4 >>>> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >>>> 0xfe1b2000 >>>> , 0x6e5a0, 0x0), at 0xfefbc9f4 >>>> (dbx) >>>> (dbx) threads >>>>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >>>> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >>>> ___nanosleep >>>> () >>>> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >>>> in __lwp_pa >>>> rk() >>>> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >>>> ___nanosleep >>>> () >>>> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >>>> in __lwp_pa >>>> rk() >>>> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >>>> in __lwp_pa >>>> rk() >>>> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >>>> in __lwp_pa >>>> rk() >>>> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >>>> __lwp_kill( >>>> ) >>>> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >>>> in __lwp_pa >>>> rk() >>>> (dbx) >>>> >>>> >>>> The crashing thread: >>>> >>>> (dbx) thread t at 27 >>>> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >>>> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >>>> 0xfe3c11f4 >>>> (dbx) where >>>> current thread: t at 27 >>>> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >>>> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >>>> 0xfe35fdd8 >>>> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >>>> 0xfe33fff8 >>>> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >>>> 0xfe46255c >>>> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >>>> 0xfe4529c8 >>>> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >>>> 0xfddf0900), at 0x >>>> fe44f2e4 >>>> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >>>> 0xfe4b4d90, 0xff2 >>>> 50434), at 0xfe44ee5c >>>> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >>>> 0x100000), >>>> at 0xfe44fa0c >>>> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, >>>> 0x12345678 >>>> ), >>>> at 0xfe44f590 >>>> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>>> 0xfffffff8, 0x0, >>>> 0xfdc53131), at 0xfe44f44c >>>> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >>>> 0x0), at 0xfe46 >>>> 470c >>>> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, >>>> 0x12345678 >>>> ), >>>> at 0xfe44f680 >>>> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>>> 0xfffffff8, 0x0, >>>> 0xfdc53661), at 0xfe44f44c >>>> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >>>> 0x0, 0xfdc538 >>>> e1), at 0xfe46470c >>>> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >>>> 0xfdc53a40, 0xfdc539 >>>> 2c, 0xfdc53928), at 0xfe42ffe0 >>>> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >>>> 0xfdc53a40), a >>>> t 0xff141d64 >>>> >>>> (too many frames for an assertion failure imho!) >>>> >>>> >>>> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >>>> 0x1000, 0x0, >>>> 0x0), at 0xff13dda4 >>>> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >>>> 0xff000000, 0x0, >>>> 0x0), at 0xff13d9e8 >>>> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >>>> 0xfddf0800, >>>> 0x69da0, 0x0), at 0xff140730 >>>> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >>>> 0xff000000, 0xff00000 >>>> 0, 0x0, 0x1), at 0xff1407d0 >>>> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >>>> 0xfdd221bc), a >>>> t 0xfefb8f04 >>>> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >>>> 0xfefc5170 >>>> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >>>> 0xfddf0800, 0x90 >>>> 410, 0x0), at 0xfefc45a8 >>>> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >>>> 0xfefc4674 >>>> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >>>> 0xfe46bc00 >>>> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >>>> 0xfe46b740, 0x1) >>>> , at 0xfe46b790 >>>> (dbx) >>>> >>>> >>>> - Jay From hosking at cs.purdue.edu Mon Jul 27 15:56:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Jul 2009 09:56:44 -0400 Subject: [M3devel] gcc error on PPC_DARWIN In-Reply-To: References: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> Message-ID: <567D958D-EBCE-4358-8D97-80688C544CAD@cs.purdue.edu> -m32 should work. On 27 Jul 2009, at 00:09, Jay K wrote: > > I kind of throw in that everywhere until/unless shown that it hurts > and isn't needed. > Indeed it doesn't always work, not always on gcc, not always on cm3cg. > > > I have this probe in Darwin.common now, since I was using an > AMD64_DARWIN machine the other day: > > > if not defined("SYSTEM_CC") > not this part > if equal(WORD_SIZE, "32BITS") > SYSTEM_CC = "32" > else > SYSTEM_CC = "64" > end > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > SYSTEM_CC = "gcc -fPIC -m" & SYSTEM_CC > local a = SYSTEM_CC & " -arch " & GccArch > this part, with -arch or not > local b = try_exec("@" & a & " -v 2>/dev/null") > if equal(b, 0) > SYSTEM_CC = a > end > %write("SYSTEM_CC is " & SYSTEM_CC & "\n") > end > if not defined("SYSTEM_LIBTOOL") > readonly SYSTEM_LIBTOOL = "libtool" > end > > > which should be redundant with the -m32/64 stuff, so try just: > > > if not defined("SYSTEM_CC") > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > SYSTEM_CC = "gcc -fPIC" > local a = SYSTEM_CC & " -arch " & GccArch > local b = try_exec("@" & a & " -v 2>/dev/null") > if equal(b, 0) > SYSTEM_CC = a > end > %write("SYSTEM_CC is " & SYSTEM_CC & "\n") > end > if not defined("SYSTEM_LIBTOOL") > readonly SYSTEM_LIBTOOL = "libtool" > end > > I know this kind of probing is inefficient -- we do it every > invocation of cm3. > We could at least limit it to if there is a need to compile C or > link -- like how GetM3BackFlags works now (sort of -- not probe > related, but just related to bootstrapping or not). > The alternative is to let users edit or have cminstall do the probe > -- and have it go stale when the tools change.. > > - Jay > > > > > ---------------------------------------- >> Date: Mon, 27 Jul 2009 00:22:58 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] gcc error on PPC_DARWIN >> >> compiler bootstrap on PPC_DARWIN failed with `invalid option 32': >> http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console >> >> Do we really require 64-bit capable tools now on all systems? >> Or did I make some stupid error again? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 27 16:53:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 16:53:08 +0200 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Quoting Tony Hosking : > Not sure if doing it that way works. Current default stack size set in > ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try > changing it there. There used to be a procedure IncreaseDefaultStackSize. IITR we needed that for several M3 applications on some platforms several years ago. But probably we should also set the default for a target platform so that all our own applications are able to run. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 17:24:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 15:24:16 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Message-ID: I don't think this is a stack overflow but I will try that. We should probably drastically increase the defaults. Like make them match whatever the underlying platform uses, or just make sure that unless the user intercedes, that we don't either. The whole notion of a limited size stack is pretty flawed imho. And much worse if you engage in reducing it from the default. How much stack do I need to leave for fopen to work? What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 16:53:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Quoting Tony Hosking : > >> Not sure if doing it that way works. Current default stack size set in >> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >> changing it there. > > There used to be a procedure IncreaseDefaultStackSize. IITR we needed > that for several M3 applications on some platforms several years ago. > > But probably we should also set the default for a target platform > so that all our own applications are able to run. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 18:26:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:26:11 +0000 Subject: [M3devel] extra files in workspace Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248711232.27188 ? cm3/m3-db/db/test/stderr 16 ? cm3/m3-db/odbc/test/stderr 17 ? cm3/m3-db/postgres95/test/stderr 18 ? cm3/m3-db/stable/test/stderr 19 ? cm3/m3-libs/arithmetic/test/stderr 20 ? cm3/m3-libs/binIO/test/PPC_LINUX 21 ? cm3/m3-libs/binIO/test/stderr 22 ? cm3/m3-libs/bitvector/test/stderr 23 ? cm3/m3-libs/libm3/tests/PPC_LINUX 24 ? cm3/m3-libs/libm3/tests/stderr 25 ? cm3/m3-libs/patternmatching/tests/stderr 26 ? cm3/m3-libs/slisp/tests/stderr 27 ? cm3/m3-libs/unittest-numeric/PPC_LINUX 28 ? cm3/m3-sys/cm3/test/PPC_LINUX 29 ? cm3/m3-sys/cm3/test/stderr 30 ? cm3/m3-sys/cm3ide/PPC_LINUX 31 ? cm3/m3-sys/m3cc/tmp-stdout-13571 32 ? cm3/m3-sys/m3quake/test/PPC_LINUX 33 ? cm3/m3-sys/m3quake/test/stderr 34 ? cm3/m3-sys/m3tests/PPC_LINUX 35 ? cm3/m3-sys/m3tests/m3tests-results.xml 36 ? cm3/m3-sys/m3tests/m3tests-results.xml.new 37 ? cm3/m3-sys/m3tests/m3tests.html 38 ? cm3/m3-tools/cvsup/cvpasswd/PPC_LINUX 39 ? cm3/m3-tools/kate/PPC_LINUX 40 ? cm3/m3-tools/m3tohtml/html we might consider having the scripts delete such things at the start of a run. Including what .cvsignore is suppressing (depending on if the desire is to clean or not). Notice that not all are in the derived directory (or rather none are, except the derived directory itself) - Jay From rcoleburn at scires.com Mon Jul 27 18:29:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 27 Jul 2009 12:29:41 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Message-ID: <4A6D9D4E.1E75.00D7.1@scires.com> In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. See the code snippet below: (* stack *) IF pp.keywordPresent("-stack") THEN (* *) TRY (* *) stackMult := pp.getNextInt(min := 1, max := 100); EXCEPT | ParseParams.Error => (* *) pp.error("A number in the range [1..100] must be specified as\n" & "the stack size multiplier after the -stack option.\n"); END; (* try *) END; (* if *) IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy Coleburn >>> Jay K 7/27/2009 11:24 AM >>> I don't think this is a stack overflow but I will try that. We should probably drastically increase the defaults. Like make them match whatever the underlying platform uses, or just make sure that unless the user intercedes, that we don't either. The whole notion of a limited size stack is pretty flawed imho. And much worse if you engage in reducing it from the default. How much stack do I need to leave for fopen to work? What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 16:53:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Quoting Tony Hosking : > >> Not sure if doing it that way works. Current default stack size set in >> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >> changing it there. > > There used to be a procedure IncreaseDefaultStackSize. IITR we needed > that for several M3 applications on some platforms several years ago. > > But probably we should also set the default for a target platform > so that all our own applications are able to run. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 27 18:33:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:33:43 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <4A6D9D4E.1E75.00D7.1@scires.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> <4A6D9D4E.1E75.00D7.1@scires.com> Message-ID: > a command line parameter to set the stack size! This is proof that the mechanism is very flawed. Imagine if all programs accepted a command line parameter to set their stack size, and chosing the right number was critical to their successful operation. !!! - Jay ________________________________ > Date: Mon, 27 Jul 2009 12:29:41 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > > > > > > > In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. > > > > If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. > > > > See the code snippet below: > > > > (* stack *) > IF pp.keywordPresent("-stack") > THEN (* *) > TRY (* *) > stackMult := pp.getNextInt(min := 1, max := 100); > EXCEPT > | ParseParams.Error => (* *) > pp.error("A number in the range [1..100] must be specified as\n" > & "the stack size multiplier after the -stack option.\n"); > END; (* try *) > END; (* if *) > IF stackMult> 1 > THEN > WITH default = Thread.GetDefaultStackSize(), > desired = default * stackMult, > increase = desired - default > DO > PutText("Increasing default stack size by a factor of " & > Fmt.Int(stackMult) & " (" & Fmt.Int(default) & ">>> " & > Fmt.Int(desired) & ").\n"); > Thread.IncDefaultStackSize(increase); > END; (* with *) > WITH default = Thread.GetDefaultStackSize() > DO > PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); > END; (* with *) > END; (* if *) > > > > Regards, > > Randy Coleburn > >>>> Jay K 7/27/2009 11:24 AM>>> > > I don't think this is a stack overflow but I will try that. > We should probably drastically increase the defaults. > Like make them match whatever the underlying platform uses, or just make > sure that unless the user intercedes, that we don't either. > > > The whole notion of a limited size stack is pretty flawed imho. > And much worse if you engage in reducing it from the default. > How much stack do I need to leave for fopen to work? > What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. > Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). > I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) > > > Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. > What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 27 Jul 2009 16:53:08 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> Quoting Tony Hosking : >> >>> Not sure if doing it that way works. Current default stack size set in >>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >>> changing it there. >> >> There used to be a procedure IncreaseDefaultStackSize. IITR we needed >> that for several M3 applications on some platforms several years ago. >> >> But probably we should also set the default for a target platform >> so that all our own applications are able to run. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Mon Jul 27 18:44:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:44:57 +0000 Subject: [M3devel] bad web pages Message-ID: [ sorry if this too rude. I've been avoiding saying anything because I haven't done anything to fix it and because my complaints are a little vague. But I am sure there is something significant here. When something bugs I often wait and see if it stops bugging me, maybe I overreact initially. But this has continued to bug me. ] I'm sorry, but our web pages are not very good. Too much information, too many details presented too early, hard to see the little a new person needs. I don't have the patience right now to go into detail, but starting here: http://www.opencm3.net/releng/ Much too much stuff. Beginners need to quickly get to a download, and quickly have hello world working, and then a link to the language and library documentation. Telling them about packages early is not useful. Having so many options as to what to download is not useful. I admit even my min vs. std separation is not great. It is embarassing either way -- either you are a huge download or you have pitiful little functionality. Though libm3 is not exactly pitiful I gather. They don't care much about quake. Just give one or two quick tutorial examples: - here is how you build a program from multiple source files - optionally here is how you build a library (obviously this information must be provided, but not super early) My other complaint is that I go here: http://modula3.elegosoft.com/ and there is a link "WWW service for CM3 and PM3" Huh? WWW Service? Aren't I already there? Perhaps I just pick a bad starting point? Is the distinction Modula-3 the language vs. the two distributions CM3 and PM3? Maybe we should ignore PM3 and equate Modula-3 with CM3, and somehow merge this stuff? The package download service? Does anyone use it? The problem, the reason I don't rewrite stuff and am just a lazy complainer, is that in total there's a bunch of stuff in there. The way it is laid out is bad. It used to take me a while to find stuff. I can't be very concrete now..maybe the organization has changed..I thought it was the stuff you have to scroll to the bottom for, but I don't use that anymore. One concrete thing is that http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes doesn't need to be so visible, it's spot could be used for something of more general use. I realize that it was more valuable when 5.1 was new, and then its value degraded gradually. It depends how much there is out there that works with 3.x?4.x?PM3 and doesn't work with CM3? Perhaps a very big part of the answer here is deb packages? - add such and such line to whatever file - apt-get modula3-min or modula3-all, or whatever you want in-between? - apt-whatever -list modula3-*? I guess we'd have to call them cm3 not modula3. - Jay From jay.krell at cornell.edu Mon Jul 27 19:17:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 17:17:51 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <4A6D9D4E.1E75.00D7.1@scires.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> <4A6D9D4E.1E75.00D7.1@scires.com> Message-ID: > I don't know of a way to increase the mainline thread stack while it is running. On NT you cannot. The stack size is set when the thread is created. Once the thread is created, that is it. Typical default thread sizes on 32bit NT are 256K and 1MB. Maybe twice that for 64bit. I think there might be a minimum that small requests get rounded up to. VirtualAlloc basically allocates in 64K chunks so you can't likely get smaller than 64K, or 60K if you consider the guard page. Some experimentation would be informative. I've seen gcc stack overflow only on non-Linux..because the default stack on Linux is huge, like 8MB. I guess that's what you get in historically single threaded environments.. If you write an NT kernel driver, then you generally have like 3 4K pages maximum, a very different environment. Basically I consider this area fairly unpredictable. Did I create the thread or did someone else create it and call me? How much stack is required by the code I'm going to call. In the absence of any solutions, best advise for the programmer is to generally conserve stack. If you must recurse, recurse only to a maximum amount determined by your code, not determined by user input. Otherwise large user input will cause you to fail in a hard to handle way. Fixed sized character buffers of 256, 1024, MAX_PATH, etc. are not a good thing to use. Doubly (or even quadruply) bad with Unicode. Despite being very fast. Another option is to use a small buffer like 64 and then heap alloc if the data is large. Or just heap alloc and have a smooth if slow performance curve against data size. At least with the heap, it is pretty much limited by address space, and running out of heap at least in C is very well defined -- you get NULL from malloc. Many people know to check for that. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] the formsedit crash > Date: Mon, 27 Jul 2009 16:33:43 +0000 > > >> a command line parameter to set the stack size! > > This is proof that the mechanism is very flawed. > Imagine if all programs accepted a command line parameter to set their stack size, and chosing the right number was critical to their successful operation. > > !!! > > - Jay > > > > ________________________________ >> Date: Mon, 27 Jul 2009 12:29:41 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> >> >> >> >> >> >> In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. >> >> >> >> If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. >> >> >> >> See the code snippet below: >> >> >> >> (* stack *) >> IF pp.keywordPresent("-stack") >> THEN (* *) >> TRY (* *) >> stackMult := pp.getNextInt(min := 1, max := 100); >> EXCEPT >> | ParseParams.Error => (* *) >> pp.error("A number in the range [1..100] must be specified as\n" >> & "the stack size multiplier after the -stack option.\n"); >> END; (* try *) >> END; (* if *) >> IF stackMult> 1 >> THEN >> WITH default = Thread.GetDefaultStackSize(), >> desired = default * stackMult, >> increase = desired - default >> DO >> PutText("Increasing default stack size by a factor of " & >> Fmt.Int(stackMult) & " (" & Fmt.Int(default) & ">>> " & >> Fmt.Int(desired) & ").\n"); >> Thread.IncDefaultStackSize(increase); >> END; (* with *) >> WITH default = Thread.GetDefaultStackSize() >> DO >> PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); >> END; (* with *) >> END; (* if *) >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay K 7/27/2009 11:24 AM>>> >> >> I don't think this is a stack overflow but I will try that. >> We should probably drastically increase the defaults. >> Like make them match whatever the underlying platform uses, or just make >> sure that unless the user intercedes, that we don't either. >> >> >> The whole notion of a limited size stack is pretty flawed imho. >> And much worse if you engage in reducing it from the default. >> How much stack do I need to leave for fopen to work? >> What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. >> Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). >> I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) >> >> >> Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. >> What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Mon, 27 Jul 2009 16:53:08 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] the formsedit crash >>> >>> Quoting Tony Hosking : >>> >>>> Not sure if doing it that way works. Current default stack size set in >>>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >>>> changing it there. >>> >>> There used to be a procedure IncreaseDefaultStackSize. IITR we needed >>> that for several M3 applications on some platforms several years ago. >>> >>> But probably we should also set the default for a target platform >>> so that all our own applications are able to run. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From eiserlohpp at yahoo.com Mon Jul 27 20:49:57 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 27 Jul 2009 11:49:57 -0700 (PDT) Subject: [M3devel] compiler status lines, output in a burst Message-ID: <34573.39026.qm@web56805.mail.re3.yahoo.com> Hi Guys, I just downloaded the latest tarball, and started compiling it with a compiler built from 20090724 (three days ago). I noticed that the output looked "jerky", unlike the normal behavior. Looking closer, it appears that the compiler descends into a package, announces that it has started, then waits. A few seconds later it emits all the ( new-source -> foo.[im]3 ) and similar lines in one burst. Did someone remove the flush at the end of a line of text? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Mon Jul 27 22:07:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:07:26 +0200 Subject: [M3devel] compiler status lines, output in a burst In-Reply-To: <34573.39026.qm@web56805.mail.re3.yahoo.com> References: <34573.39026.qm@web56805.mail.re3.yahoo.com> Message-ID: <20090727220726.fu6kbgwr3koooowg@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Guys, > > I just downloaded the latest tarball, and started compiling > it with a compiler built from 20090724 (three days ago). > > I noticed that the output looked "jerky", unlike the > normal behavior. Looking closer, it appears that the > compiler descends into a package, announces that it has > started, then waits. A few seconds later it emits all > the ( new-source -> foo.[im]3 ) and similar lines in > one burst. > > Did someone remove the flush at the end of a line of text? That should be fixed easily. Stay tuned, just waiting for a test in Hudson... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 22:49:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:49:26 +0200 Subject: [M3devel] bad web pages In-Reply-To: References: Message-ID: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> No offense taken. Any volunteers for working on improving the web presentation are welcome. The official domains are opencm3.net and modula3.org. Everything else should be left to Elego. I'd really appreciate if someone with the appropriate knowledge in design would step in. I don't think anybody is interested in doing that, though. I'd say that 99% of what is there has been structured and presented by me in the simplest way just to publish the available information at all. Some people have made concrete change suggestions, and I'm usually trying to follow and integrate them. Let's not try a complete overhaul for this release. Just fix the most blatant errors and no-gos. Everything else will take months. The releng pages have been open for discussion here for several weeks now; they are still not public (i.e. not linked to the other pages) of opencm3.net. Suggestions may also simply be checked in (everything is in the repo), preferrably on a branch, so that everyone can have a look at it. It's also much more effective. I haven't got the time to process half a dozen of new and probably conflicting suggestions. What's not open for discussion in my eyes any more is the structure of the release archives. We'll just use what is described there, or it will take months till we get anywhere. It will also be the last time that I coordinate a CM3 release. Everyone around me is already complaining :-( Olaf Quoting Jay K : > [ > sorry if this too rude. > I've been avoiding saying anything because I haven't done anything > to fix it and because my complaints are a little vague. But I am > sure there is something significant here. When something bugs I > often wait and see if it stops bugging me, maybe I overreact > initially. But this has continued to bug me. > ] > > > I'm sorry, but our web pages are not very good. > Too much information, too many details presented too early, hard to > see the little a new person needs. > > > I don't have the patience right now to go into detail, but starting here: > > > http://www.opencm3.net/releng/ > > > Much too much stuff. > > > Beginners need to quickly get to a download, and quickly have hello > world working, and then a link to the language and library > documentation. > > > Telling them about packages early is not useful. > Having so many options as to what to download is not useful. > I admit even my min vs. std separation is not great. > It is embarassing either way -- either you are a huge download or > you have pitiful little functionality. Though libm3 is not exactly > pitiful I gather. > > > They don't care much about quake. > Just give one or two quick tutorial examples: > - here is how you build a program from multiple source files > - optionally here is how you build a library (obviously this > information must be provided, but not super early) > > > My other complaint is that I go here: > > > http://modula3.elegosoft.com/ > > > and there is a link "WWW service for CM3 and PM3" > > Huh? WWW Service? Aren't I already there? > Perhaps I just pick a bad starting point? > > > Is the distinction Modula-3 the language vs. the two distributions > CM3 and PM3? > Maybe we should ignore PM3 and equate Modula-3 with CM3, and somehow > merge this stuff? > > > The package download service? Does anyone use it? > > > The problem, the reason I don't rewrite stuff and am just a lazy > complainer, is that in total there's a bunch of stuff in there. The > way it is laid out is bad. It used to take me a while to find stuff. > > > I can't be very concrete now..maybe the organization has changed..I > thought it was the stuff you have to scroll to the bottom for, but I > don't use that anymore. > > > One concrete thing is that > http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes doesn't > need to be so > visible, it's spot could be used for something of more general use. > I realize that it was more valuable when 5.1 was new, and then its > value degraded gradually. > It depends how much there is out there that works with 3.x?4.x?PM3 > and doesn't work with CM3? > > > > Perhaps a very big part of the answer here is deb packages? > - add such and such line to whatever file > - apt-get modula3-min or modula3-all, or whatever you want in-between? > - apt-whatever -list modula3-*? > > > I guess we'd have to call them cm3 not modula3. > > > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 22:50:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:50:23 +0200 Subject: [M3devel] compiler status lines, output in a burst In-Reply-To: <34573.39026.qm@web56805.mail.re3.yahoo.com> References: <34573.39026.qm@web56805.mail.re3.yahoo.com> Message-ID: <20090727225023.zf2wctvsisgswckw@mail.elegosoft.com> Quoting Peter Eiserloh : > I noticed that the output looked "jerky", unlike the > normal behavior. Looking closer, it appears that the > compiler descends into a package, announces that it has > started, then waits. A few seconds later it emits all > the ( new-source -> foo.[im]3 ) and similar lines in > one burst. should be fixed now Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 28 01:10:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 23:10:15 +0000 Subject: [M3devel] getting Tinderbox to green? Message-ID: Linux/x86, Linux/sparc, Linux/ppc. Sparc hit access denied uploading to birch. Maybe transient network problem. The others succeeded builds, failed tests. Failed tests is normal, right? And should be green? They stay orange. I also see that the yellow doesn't change to green or orange until the next build is started, I'm pretty sure. I somehow got very luck with my one SOLgnu run. It was green on almost my first try. - Jay From jay.krell at cornell.edu Tue Jul 28 05:09:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 03:09:36 +0000 Subject: [M3devel] getting Tinderbox to green? Message-ID: I think on PPC_LINUX I just need to delete the old pkg and lib stores particularly to remove the old libodbc.so. On I386_LINUX there is a different problem linking the db test. I might have to install something extra there. Could be a Gentoo vs. Debian thing. Not likely any real problem in the Modula-3 tree here, but a problem with my machine configuration. SPARC32_LINUX's last run that uploaded had the m3gdb problem, so still waiting to see. Maybe the next runs will go green, maybe. btw, I'm pretty sure this is all feeds directly into Hudson, like, I'm not wasting time on Tinderbox. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: getting Tinderbox to green? > Date: Mon, 27 Jul 2009 23:10:15 +0000 > > > Linux/x86, Linux/sparc, Linux/ppc. > Sparc hit access denied uploading to birch. > Maybe transient network problem. > > The others succeeded builds, failed tests. > Failed tests is normal, right? > And should be green? > They stay orange. > I also see that the yellow doesn't change to green or orange > until the next build is started, I'm pretty sure. > > I somehow got very luck with my one SOLgnu run. > It was green on almost my first try. > > > - Jay > From rcoleburn at scires.com Tue Jul 28 05:24:26 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 27 Jul 2009 23:24:26 -0400 Subject: [M3devel] new install on Windows Vista Message-ID: <4A6E36C0.1E75.00D7.1@scires.com> Jay: I am attempting a new install on Windows Vista. I have a question about the config files. I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? Thanks for your help! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 06:22:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 04:22:25 +0000 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6E36C0.1E75.00D7.1@scires.com> References: <4A6E36C0.1E75.00D7.1@scires.com> Message-ID: [keeping you on the thread in case of truncation] I would do all the clean each package first, then build and ship each, two passes over the list clean in the first pass build and ship in the second That is hard to explain clearly but I think you understand. Given the packages a b c. clean a clean b clean c build a ship a build b ship b build c ship c is what I do, but it should also work as: clean a build a ship a clean b build b ship b clean c build c ship c which is what I think you described. My python files do deal with the config files. You might try reading some of it? (not intended rudely, as evidenced by further explanation here) Here is the current way: for each file name in cvsroot\m3-sys\cminstall\src\config-no-install and cvsroot\m3-sys\cminstall\src\config delete corresponding file in \cm3\bin That is a "cleanup" step. Not applicable if starting from scratch, harmless. mkdir \cm3\bin\config copy cvsroot\m3-sys\cminstall\src\config-no-install \cm3\bin\config create \cm3\bin\cm3.cfg with the following exact contents: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) There is no meta syntax there. - forward slashes work on Windows - path() is a function that returns the directory of the file calling it - HOST is builtin on newer builds and is a good default for TARGET (We should use this in the distribution archives.) Some of this is taste and the system is flexible. If you wanted, you could put all the files in \cm3\bin, or \whatever. You can make cm3.cfg look in various places. That is what I actually do -- I copy cvsroot\m3-sys\cminstall\src\config-no-install\cm3.cfg to \cm3\bin. It ends up picking up %CM3_ROOT%\m3-sys\cminstall\src\config-no-install\TARGET, so I can edit just one file while in development and not keep having to copy it around. Otherwise I'd get an error in one file in \cm3\bin, fix it, and then remember to copy it into the source tree to check it in. > esp. given an aribitrary old minimal installation as a starting point Yes. I recently removed a lot of the very old compatibility but I have used these exact config files with fairly old builds and run upgrade.cmd or upgrade.py. They were meant to work with a wide range of cm3 versions and on multiple platforms. If you want I can put the compatibility back. There were workarounds for bugs, not yet provided features, etc. The workarounds dynamically adapted to what capabilities the cm3/cm3cg they were using had, and they new for newer platforms to just assume things work well. There are more newer platforms than older platforms so it was kind of annoying to carry it all around, but it does work. I can put it back. You might also want to read README.jay that I checked in. I'll summarize it here: create new empty directory, and bin and bin\config thereof. Put cm3 and cm3cg in bin, copy all the config files to bin\config, create cm3.cfg as shown earlier. Given a recent cm3 (e.g. one that supports LONGINT) that is all you need to build the system starting with import-libs or m3core and on up. (import-libs is almost unnecessary. It is a workaround for that - older cm3 builds contained bogus files - some but very few native toolsets don't have the requisite files, like Visual C++ 2003 Express If you have a decent toolset and start with an old cm3, you can just delete the toplevel lib directory to get started and skip import-libs..but it builds super fast anyway). You don't likely even need cm3cg, it just saves time. And you don't need it on NT386 of course. If you have too old of a cm3, then you start with cm3 and pkg\m3core and pkg\libm3, and start with import-libs and sysutils, skipping m3core and libm3. (I'm assuming both m3core and libm3 use LONGINT, if they don't, then..) Oh, also older and even current cm3 can't build certain versions of m3core and/or libm3 (I think just libm3) between old and present due to the platform list. But current m3core and libm3 don't have that problem. m3-sys\cminstall\src\config is dead, as are all the config files around m3-sys\cm3\config. I deleted m3-sys\cm3\config but Tony added some back. I'm trying to wait until after this release to delete a lot of the dead stuff. Trying also to consider if some of it has historical/reference value. Like all the Unix *.i3 files. Maybe just comment those all out instead of deleting them. I know there is CVS history but it much easier to see what is dead and present than dead and gone, as long as there are good hints that it is dead, like commenting out every line. "a lot has changed in the config files since 5.8.1" I imagine would be - removal of compatibility stuff - possibly the use of symlinks and removal of hardlinks - having make_lib call skip_lib - oh, right, refactoring of all the toplevel files to include(architecture) and include(os). That had been bugging me for a long time so I finally did it. Basically the original authors of the config files either - liked monolithic files - didn't consider the proliferation of OS across multiple/many architectures These days we have fairly few OS, but many OS x architecture. NetBSD on everything, Linux on everything, everything else still on a few Let me know if that doesn't answer everything or if you have further questions. Once I have the Tinderbox runs running better on Posix sysetms, I will face the choice for NT386 of using Cygwin sh to drive it all, or rewriting all the .sh in .cmd or .py or .js. I'm strongly considering rewriting in .py. Rewriting is also a good way to gain understanding, you have to read and understand every line. - Jay ________________________________ > Date: Mon, 27 Jul 2009 23:24:26 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] new install on Windows Vista > > > > > > > > Jay: > > > > I am attempting a new install on Windows Vista. I have a question about the config files. > > > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > > > It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. > > > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > > > Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. > > > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. > > > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? > > > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? > > > > Thanks for your help! > > > > Regards, > > Randy Coleburn From lists at darko.org Tue Jul 28 06:47:08 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 06:47:08 +0200 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6E36C0.1E75.00D7.1@scires.com> References: <4A6E36C0.1E75.00D7.1@scires.com> Message-ID: <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> I happen to be doing the same thing at the moment (on XP). Have we got an installer for this in the works? And Inno Setup one should be pretty easy if not. On 28/07/2009, at 5:24 AM, Randy Coleburn wrote: > Jay: > > I am attempting a new install on Windows Vista. I have a question > about the config files. > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > It is unzipped to C:\cm3. Note that I also have a complete checkout > of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also > installed Visual C++ 2008 Express. > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C: > \cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, > hoping that this will indeed upgrade the compiler in the proper > order, based on PkgInfo.txt. If I invoke my script as follows "do- > cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 - > build", and "cm3 -ship" command sequence to each package identified > in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > Perhaps this is a flawed plan; if so, let me know. I know there are > various scripts and python that may already purport to do what I > want to do, but please humor me. I am trying to learn the actual > low-level steps required to do the install and upgrade, beginning > with the minimal distribution. In my view, once I have the minimal > binary distro plus the new sources, I ought to be able to use the > cm3 commands (perhaps scripted) to rebuild everything properly, as > long as I do it in the correct order. > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin > \cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C: > \Sandbox\m3-sys\cminstall\src" we have a config folder and a config- > no-install folder. In the past, I've been copying the contents of > the config-no-install folder to "C:\cm3\bin". (1) Is this correct? > If not, please explain. > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If > not, how/when/should this folder be updated? > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, > it seems a lot has changed, hence my questions. I also wonder that > if someone used the python or other scripts, do these handle > updating the various config stuff, esp. given an aribitrary old > minimal installation as a starting point? > > Thanks for your help! > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 07:04:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 05:04:49 +0000 Subject: [M3devel] new install on Windows Vista In-Reply-To: <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> References: <4A6E36C0.1E75.00D7.1@scires.com> <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi created by automation in cvsroot/scripts/python/pylib.py, via scripts/python/make-dist.py. - Jay ________________________________ > From: lists at darko.org > To: m3devel at elegosoft.com > Date: Tue, 28 Jul 2009 06:47:08 +0200 > Subject: Re: [M3devel] new install on Windows Vista > > I happen to be doing the same thing at the moment (on XP). Have we got an installer for this in the works? And Inno Setup one should be pretty easy if not. > > > On 28/07/2009, at 5:24 AM, Randy Coleburn wrote: > > Jay: > > I am attempting a new install on Windows Vista. I have a question about the config files. > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? > > Thanks for your help! > > Regards, > Randy Coleburn > From wagner at elegosoft.com Tue Jul 28 07:24:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 07:24:59 +0200 Subject: [M3devel] getting Tinderbox to green? In-Reply-To: References: Message-ID: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> Quoting Jay K : > Linux/x86, Linux/sparc, Linux/ppc. > Sparc hit access denied uploading to birch. > Maybe transient network problem. > > The others succeeded builds, failed tests. > Failed tests is normal, right? > And should be green? > They stay orange. That's expected. All release builds were orange as long as I remember. We always had failed tests. > I also see that the yellow doesn't change to green or orange > until the next build is started, I'm pretty sure. That's strange. It should get green/orange/red as soon as the results are in. > I somehow got very luck with my one SOLgnu run. > It was green on almost my first try. So it doesn't run any tests? Just compiles? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lists at darko.org Tue Jul 28 07:24:25 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 07:24:25 +0200 Subject: [M3devel] bad web pages In-Reply-To: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> References: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> Message-ID: I don't think the visiual presentation is the issue, but the oganisation could be improved. I think visiually it should look like the M3 Language Definition and the like. I'll have a go at re- organising it. On 27/07/2009, at 10:49 PM, Olaf Wagner wrote: > No offense taken. Any volunteers for working on improving the > web presentation are welcome. > > The official domains are opencm3.net and modula3.org. > Everything else should be left to Elego. > > I'd really appreciate if someone with the appropriate knowledge > in design would step in. I don't think anybody is interested in > doing that, though. I'd say that 99% of what is there has been > structured and presented by me in the simplest way just to publish > the available information at all. > > Some people have made concrete change suggestions, and I'm usually > trying to follow and integrate them. > > Let's not try a complete overhaul for this release. Just fix the most > blatant errors and no-gos. Everything else will take months. > > The releng pages have been open for discussion here for several weeks > now; they are still not public (i.e. not linked to the other pages) > of opencm3.net. > > Suggestions may also simply be checked in (everything is in the repo), > preferrably on a branch, so that everyone can have a look at it. > It's also much more effective. I haven't got the time to process > half a dozen of new and probably conflicting suggestions. > > What's not open for discussion in my eyes any more is the structure > of the release archives. We'll just use what is described there, > or it will take months till we get anywhere. It will also be the > last time that I coordinate a CM3 release. Everyone around me is > already complaining :-( > > Olaf > > Quoting Jay K : > >> [ >> sorry if this too rude. >> I've been avoiding saying anything because I haven't done anything >> to fix it and because my complaints are a little vague. But I am >> sure there is something significant here. When something bugs I >> often wait and see if it stops bugging me, maybe I overreact >> initially. But this has continued to bug me. >> ] >> >> >> I'm sorry, but our web pages are not very good. >> Too much information, too many details presented too early, hard >> to see the little a new person needs. >> >> >> I don't have the patience right now to go into detail, but starting >> here: >> >> >> http://www.opencm3.net/releng/ >> >> >> Much too much stuff. >> >> >> Beginners need to quickly get to a download, and quickly have >> hello world working, and then a link to the language and library >> documentation. >> >> >> Telling them about packages early is not useful. >> Having so many options as to what to download is not useful. >> I admit even my min vs. std separation is not great. >> It is embarassing either way -- either you are a huge download or >> you have pitiful little functionality. Though libm3 is not exactly >> pitiful I gather. >> >> >> They don't care much about quake. >> Just give one or two quick tutorial examples: >> - here is how you build a program from multiple source files >> - optionally here is how you build a library (obviously this >> information must be provided, but not super early) >> >> >> My other complaint is that I go here: >> >> >> http://modula3.elegosoft.com/ >> >> >> and there is a link "WWW service for CM3 and PM3" >> >> Huh? WWW Service? Aren't I already there? >> Perhaps I just pick a bad starting point? >> >> >> Is the distinction Modula-3 the language vs. the two distributions >> CM3 and PM3? >> Maybe we should ignore PM3 and equate Modula-3 with CM3, and >> somehow merge this stuff? >> >> >> The package download service? Does anyone use it? >> >> >> The problem, the reason I don't rewrite stuff and am just a lazy >> complainer, is that in total there's a bunch of stuff in there. >> The way it is laid out is bad. It used to take me a while to find >> stuff. >> >> >> I can't be very concrete now..maybe the organization has >> changed..I thought it was the stuff you have to scroll to the >> bottom for, but I don't use that anymore. >> >> >> One concrete thing is that http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes >> doesn't need to be so >> visible, it's spot could be used for something of more general use. >> I realize that it was more valuable when 5.1 was new, and then its >> value degraded gradually. >> It depends how much there is out there that works with 3.x?4.x?PM3 >> and doesn't work with CM3? >> >> >> >> Perhaps a very big part of the answer here is deb packages? >> - add such and such line to whatever file >> - apt-get modula3-min or modula3-all, or whatever you want in- >> between? >> - apt-whatever -list modula3-*? >> >> >> I guess we'd have to call them cm3 not modula3. >> >> >> - Jay >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Jul 28 07:41:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 05:41:44 +0000 Subject: [M3devel] getting Tinderbox to green? In-Reply-To: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> References: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> Message-ID: > That's expected. All release builds were orange as long as I remember. > We always had failed tests. But your builds are green. I think there might be two measures of test failure. Building the tests vs. running the tests? I still have build failures wrt db. I think that is holding it up. Tony's Solaris runs do too. http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-SOLgnu.html#tr_m3-db-odbc >> I somehow got very luck with my one SOLgnu run. >> It was green on almost my first try. > So it doesn't run any tests? Just compiles? Yeah you are right: [start run-tests 2009.07.26 05:08:06] 6600 cd /tmp/build-cm3-20090726-031802-jMaOBg/build 6601 [end run-tests 2009.07.26 05:08:06] I must have forgotten to comment out to run the tests. I think the reason my earlier builds never finished was probably they were hung trying to scp/ssh to birch without the username fixed. I thought it was something related to not running the tests, but now I doubt that. I guess the way to get green asap is remove that edit and don't run the tests at all. I'll try not to go that way though. Hot weather this week also, not sure what I'm going to do.. - Jay From eiserlohpp at yahoo.com Tue Jul 28 08:37:08 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 27 Jul 2009 23:37:08 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 33, Issue 104 Message-ID: <28748.61011.qm@web56806.mail.re3.yahoo.com> Hi Olaf, I just wanted to say thank you! You have been doing a great job. A compiler and development environment such as CM3 is a very large software suite, and to coordinate a software release is never an easy job. Sure the web pages can use some sprucing up, big deal! Like you said, all the web pages are in the CVS repo, any one with write access to the repo could change them. It may seem like there is a lot of complaining, and it is, but what has everyone jazzed up at the moment (okay last few months), is that shortly, all the work we have been doing will be seeing a much larger audience, and we want our favorite project to look its best. What we all should remember is that we all have real lives, away from the computer and modula-3. None of us has enough time to do _everything_ we want. BTW: I just wanted bring your attention to my latest build of Debian packages for AMD64_LINUX on "lenny". I built it today from cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. http://www.eiserloh.org/mirrors/modula3/ If you have a Debian-lenn-AM64 machine, could you try it out. Maybe, even download the source package, and try building it yourself. The source package should work with any architecture supported by Debian. Please comment on any improvements I can make to these debian packages. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > Date: Mon, 27 Jul 2009 22:49:26 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] bad web pages It will also be the > last time that I coordinate a CM3 release. Everyone around > me is already complaining :-( > > Olaf From lists at darko.org Tue Jul 28 09:24:38 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 09:24:38 +0200 Subject: [M3devel] Dependency on msvcr80.dll Message-ID: After intalling the latest VC++ Express which is 2008 or version 9 and building with your min distribution I found it was dependent on msvcr80.dll. Is this hard coded somewhere - should it use the msvcr90.dll? Is there a correct way to resolve it? Cheers, Darko. From jay.krell at cornell.edu Tue Jul 28 09:28:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 07:28:25 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: This is a problem I found and reported here last week. Until otherwise figured out, we have to provide a build per supported toolset/runtime. It is built into the binaries/libraries, it is their dependencies. I don't fully understand what is going on. Just because m3core.dll uses a particular .dll, does not foist that direct dependency on its users. However if you want to get malloced pointer from it and then free it, or an fopen FILE* from it and fread/fclose it, then you do have to agree. malloc is very easy to do without, and besides, most/all of this stuff is wrapped up -- you know, if you call UntracedHeapAllocate (whatever it is called) you can't then call free, you have to call UntracedHeapFree (whatever it is called) - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Subject: Dependency on msvcr80.dll > Date: Tue, 28 Jul 2009 09:24:38 +0200 > CC: m3devel at elegosoft.com > > After intalling the latest VC++ Express which is 2008 or version 9 and > building with your min distribution I found it was dependent on > msvcr80.dll. Is this hard coded somewhere - should it use the > msvcr90.dll? Is there a correct way to resolve it? > > Cheers, > Darko. > From jay.krell at cornell.edu Tue Jul 28 09:28:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 07:28:54 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: (and I opened a Trac ticket too) ---------------------------------------- > From: jay.krell at cornell.edu > To: lists at darko.org > CC: m3devel at elegosoft.com > Subject: RE: Dependency on msvcr80.dll > Date: Tue, 28 Jul 2009 07:28:25 +0000 > > > This is a problem I found and reported here last week. > > > Until otherwise figured out, we have to provide a build per supported toolset/runtime. > It is built into the binaries/libraries, it is their dependencies. > > > I don't fully understand what is going on. > > > Just because m3core.dll uses a particular .dll, does not foist that direct dependency on its users. However if you want to get malloced pointer from it and then free it, or an fopen FILE* from it and fread/fclose it, then you do have to agree. > > > malloc is very easy to do without, and besides, most/all of this stuff is wrapped up -- you know, if you call UntracedHeapAllocate (whatever it is called) you can't then call free, you have to call UntracedHeapFree (whatever it is called) > > > - Jay > > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Subject: Dependency on msvcr80.dll >> Date: Tue, 28 Jul 2009 09:24:38 +0200 >> CC: m3devel at elegosoft.com >> >> After intalling the latest VC++ Express which is 2008 or version 9 and >> building with your min distribution I found it was dependent on >> msvcr80.dll. Is this hard coded somewhere - should it use the >> msvcr90.dll? Is there a correct way to resolve it? >> >> Cheers, >> Darko. >> From jay.krell at cornell.edu Tue Jul 28 11:35:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 09:35:31 +0000 Subject: [M3devel] odbc errors Message-ID: odbc errors Tony, everyone, please read and then do like this: rm -rf /usr/local/cm3/pkg/*odbc* rm -rf /usr/local/cm3/lib/*odbc* cd root/cm3/m3-db rm -rf odbc cvs -z3 upd -dAP odbc cd odbc cm3 cm3 -ship cd ~/work/cm3-inst find . | grep odbc | xargs rm - Jay From hendrik at topoi.pooq.com Tue Jul 28 11:39:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Jul 2009 05:39:32 -0400 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) In-Reply-To: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> References: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> Message-ID: <20090728093932.GA7708@topoi.pooq.com> On Mon, Jul 27, 2009 at 03:31:55PM +0200, Olaf Wagner wrote: > Quoting Jay K : > > >CVS checkout and update of an entire tree seem to be extremely unreliable. > >It takes a while and often times out. > > It should not take longer than about 5 minutes, and considering > the number of files and amount of data to be transferred, that's > quite acceptable. > > If we really run out of resources on birch, we may need to set up > a public r/o copy of the repository for cvs access. Or switch to a distrubited system like monotone, which I've been able to spend far too little time on lately. Sorry. -- hendrik From jay.krell at cornell.edu Tue Jul 28 11:40:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 09:40:33 +0000 Subject: [M3devel] odbc errors In-Reply-To: References: Message-ID: In the cm3-inst case you can just rm -rf */lib */pkg. You don't need them at the start of a Tinderbox run, at least not for last-ok. You do need them for last-rel I believe though (I've never run that). I've also deleted my entire lib and pkg install for good measure, but I know I can easily rebuild them and the "work/cm3-inst" is more important right now, that's where Tinderbox/Hudson work. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Tue, 28 Jul 2009 09:35:31 +0000 > Subject: [M3devel] odbc errors > > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay From jay.krell at cornell.edu Tue Jul 28 12:40:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 10:40:40 +0000 Subject: [M3devel] executable named "test" Message-ID: I noticed I had an executable named "test" in my cm3 install. It is related to caltech-parser, but I don't know exactly where it came from, or if it is still being produced. There is no capital P Program("test") just lowercase program("test") which means they only ship to the pkg directory and not bin. Just a note for folks to check for this and delete it. It probably only occurs if you have run the Tinderbox/Hudson stuff. And even then I'm not sure how/when/where/why. - Jay From hendrik at topoi.pooq.com Tue Jul 28 12:51:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Jul 2009 06:51:37 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <20090728105137.GC7708@topoi.pooq.com> On Sat, Jul 18, 2009 at 11:50:13PM +0000, Jay K wrote: > > cm3ide is quite unusual in being browser based and that really limits > it, esp. targeting browsers from long ago with just a bunch of html, > using Flash or Silverlight can result in a browser-based app as good > as a non-browser-based app. Please, don't require proprietary stuff in the browser. -- hendrik From jay.krell at cornell.edu Tue Jul 28 14:07:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 12:07:50 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: Try these that I just made? They were built with VC 9.0: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip I didn't test them (too much combinatorial explosion -- four things to test!) and the readme from before: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt Olaf, there is a LOT more in the snaps directory than the snapshot-index lists. A lot. Also my archives contain more of the licenses, so many that I put them in a subdirectory. - Jay From wagner at elegosoft.com Tue Jul 28 14:24:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 14:24:50 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: <20090728142450.ksxo5jvx8gkoksco@mail.elegosoft.com> Quoting Jay K : > Try these that I just made? > > They were built with VC 9.0: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip > > I didn't test them (too much combinatorial explosion -- four things to test!) > > and the readme from before: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt > > Olaf, there is a LOT more in the snaps directory than the > snapshot-index lists. > A lot. Also my archives contain more of the licenses, so many that I > put them in a subdirectory. Yes. Feel free to fix ;-) Or just open a ticket for the next release... It's probably just a pattern mismatch (snapshot lists, not copyrights). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 28 14:45:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 12:45:33 +0000 Subject: [M3devel] too many loops through packages? Message-ID: Tinderbox run..compile done, tests running..and I see m3gdb running configure. I think extra work is being done.. I guess it is a bunch of incremental builds and they don't take long? - Jay From wagner at elegosoft.com Tue Jul 28 15:05:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 15:05:38 +0200 Subject: [M3devel] too many loops through packages? In-Reply-To: References: Message-ID: <20090728150538.1h0ac4s2og0cg0os@mail.elegosoft.com> Quoting Jay K : > Tinderbox run..compile done, tests running..and I see m3gdb running > configure. > I think extra work is being done.. > I guess it is a bunch of incremental builds and they don't take long? There are not really incremental builds in Tinderbox. Everything is checked out fresh and built from scratch. And there are several tests performing the same builds with slightly different contexts or targets. I'm trying to make the Hudson builds a little bit more incremental. m3cc is already factored out; m3gdb should be, too. The rest (M3 :-) builds really fast. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Jul 28 15:39:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 09:39:45 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: Message-ID: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, so exactly what should I be deleting? And why? On 28 Jul 2009, at 05:35, Jay K wrote: > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 15:51:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 13:51:42 +0000 Subject: [M3devel] odbc errors In-Reply-To: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: Whereever you have it installed. The Modula-3 libodbc* was perhaps in conflict with other libodbc*. There were at least warnings to this affect in some builds. So it was renamed libm3odbc. However the old one isn't automatically deleted. I think we can always delete it -- assuming that cm3 libraries aren't in the same directory as non-cm3 libraries but Olaf said not to. If you look at your Solaris Tinderbox test results you will see some red I believe caused by this -- not deleting the old cm3 libodbc, whereever it is. I /think/ this failure to /build/ the tests is why the red or orange status on Tinderbox instead of green. But I'm not sure yet since I haven't gotten things to turn green yet. Maybe we can only get green on the builds that don't run the tests?...er..yeah that would explain why only lastok builds are green and lastrelease builds are not..so I guess I can declare success on Linux x86/ppc/sparc.. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Jul 2009 09:39:45 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] odbc errors > > Umm, I am confused. On my niagara box I don't have /usr/local/cm3, so exactly what should I be deleting? And why? > > On 28 Jul 2009, at 05:35, Jay K wrote: > > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay > From hosking at cs.purdue.edu Tue Jul 28 17:36:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 11:36:39 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: OK, deleting those now. On 28 Jul 2009, at 09:51, Jay K wrote: > > Whereever you have it installed. > > > The Modula-3 libodbc* was perhaps in conflict with other libodbc*. > There were at least warnings to this affect in some builds. > So it was renamed libm3odbc. However the old one isn't automatically > deleted. > I think we can always delete it -- assuming that cm3 libraries > aren't in the same directory as non-cm3 libraries but Olaf said not > to. > > > If you look at your Solaris Tinderbox test results you will see some > red I believe caused by this -- not deleting the old cm3 libodbc, > whereever it is. > > > I /think/ this failure to /build/ the tests is why the red or orange > status on Tinderbox instead of green. > But I'm not sure yet since I haven't gotten things to turn green yet. > Maybe we can only get green on the builds that don't run the > tests?...er..yeah that would explain why only lastok builds are > green and lastrelease builds are not..so I guess I can declare > success on Linux x86/ppc/sparc.. > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Jul 2009 09:39:45 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] odbc errors >> >> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, >> so exactly what should I be deleting? And why? >> >> On 28 Jul 2009, at 05:35, Jay K wrote: >> >> >> odbc errors >> >> Tony, everyone, please read and then do like this: >> >> rm -rf /usr/local/cm3/pkg/*odbc* >> rm -rf /usr/local/cm3/lib/*odbc* >> cd root/cm3/m3-db >> rm -rf odbc >> cvs -z3 upd -dAP odbc >> cd odbc >> cm3 >> cm3 -ship >> >> >> cd ~/work/cm3-inst >> find . | grep odbc | xargs rm >> >> >> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 28 17:44:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 11:44:50 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: I don't have any libodbc installed anywhere in my tinderbox builds. Must be something else going on. On 28 Jul 2009, at 11:36, Tony Hosking wrote: > OK, deleting those now. > > > On 28 Jul 2009, at 09:51, Jay K wrote: > >> >> Whereever you have it installed. >> >> >> The Modula-3 libodbc* was perhaps in conflict with other libodbc*. >> There were at least warnings to this affect in some builds. >> So it was renamed libm3odbc. However the old one isn't >> automatically deleted. >> I think we can always delete it -- assuming that cm3 libraries >> aren't in the same directory as non-cm3 libraries but Olaf said not >> to. >> >> >> If you look at your Solaris Tinderbox test results you will see >> some red I believe caused by this -- not deleting the old cm3 >> libodbc, whereever it is. >> >> >> I /think/ this failure to /build/ the tests is why the red or >> orange status on Tinderbox instead of green. >> But I'm not sure yet since I haven't gotten things to turn green yet. >> Maybe we can only get green on the builds that don't run the >> tests?...er..yeah that would explain why only lastok builds are >> green and lastrelease builds are not..so I guess I can declare >> success on Linux x86/ppc/sparc.. >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Jul 2009 09:39:45 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] odbc errors >>> >>> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, >>> so exactly what should I be deleting? And why? >>> >>> On 28 Jul 2009, at 05:35, Jay K wrote: >>> >>> >>> odbc errors >>> >>> Tony, everyone, please read and then do like this: >>> >>> rm -rf /usr/local/cm3/pkg/*odbc* >>> rm -rf /usr/local/cm3/lib/*odbc* >>> cd root/cm3/m3-db >>> rm -rf odbc >>> cvs -z3 upd -dAP odbc >>> cd odbc >>> cm3 >>> cm3 -ship >>> >>> >>> cd ~/work/cm3-inst >>> find . | grep odbc | xargs rm >>> >>> >>> - Jay >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 28 22:45:27 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Jul 2009 16:45:27 -0400 Subject: [M3devel] new install on Windows Vista Message-ID: <4A6F2B27020000D70005D660@scires.com> Jay: You stated: >>> Jay K 07/28/09 12:24 AM >>> create \cm3\bin\cm3.cfg with the following exact contents: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) I am looking at the cm3.cfg you supplied with the d5.8.2.zip file. It has the following: INSTALL_ROOT = (path() & "/..") include(path() & "/config/NT386") Should it be HOST or NT386 ? Also, are the extra parenthesis in the first line needed? Thanks for your help. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 22:52:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Jul 2009 13:52:40 -0700 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6F2B27020000D70005D660@scires.com> References: <4A6F2B27020000D70005D660@scires.com> Message-ID: Host or nt386 ok. Host is like target but is the running cm3, vs. what it is building, often the same thing and using host here makes them the same. (native build vs. cross build) Parens probably not needed right. If it works it is right. It won't appear to work but do the wrong thing. - Jay (phone) On Jul 28, 2009, at 1:45 PM, "Randy Coleburn" wrote: > Jay: > > You stated: > >>> Jay K 07/28/09 12:24 AM >>> > create \cm3\bin\cm3.cfg with the following exact contents: > INSTALL_ROOT = path() & "/.." > include(path() & "/config/" & HOST) > > I am looking at the cm3.cfg you supplied with the d5.8.2.zip file. > It has the following: > INSTALL_ROOT = (path() & "/..") > include(path() & "/config/NT386") > Should it be HOST or NT386 ? > Also, are the extra parenthesis in the first line needed? > > Thanks for your help. > --Randy From lists at darko.org Wed Jul 29 04:33:03 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 29 Jul 2009 04:33:03 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Yep, they work. Can you only use the version of VC that the compiler was built with? On 28/07/2009, at 2:07 PM, Jay K wrote: > > Try these that I just made? > > They were built with VC 9.0: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip > > I didn't test them (too much combinatorial explosion -- four things > to test!) > > and the readme from before: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt > > Olaf, there is a LOT more in the snaps directory than the snapshot- > index lists. > A lot. Also my archives contain more of the licenses, so many that I > put them in a subdirectory. > > > - Jay From jay.krell at cornell.edu Wed Jul 29 05:16:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 03:16:26 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> References: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Message-ID: The compiler isn't relevant. The libraries are. You might as well consider them as one indivisable unit, but they aren't quite. I don't yet fully understand the situation. Until/unless I/we do, we'll build a distribution per VC version. I should have renamed the below cm3-min-NT386-d5.8.2-vc90.zip or such but I was lazy and took advantage of there being no other 5.8.2 currently. Stay tuned (but don't hold your breath) for cm3-min-NT386-d5.8.2-vc80.zip and speak up as to which, IF ANY, of these is desired: cm3-min-NT386-d5.8.2-vc71.zip cm3-min-NT386-d5.8.2-vc70.zip cm3-min-NT386-d5.8.2-vc60.zip cm3-min-NT386-d5.8.2-vc50.zip cm3-min-NT386-d5.8.2-vc42.zip cm3-min-NT386-d5.8.2-vc41.zip cm3-min-NT386-d5.8.2-vc40.zip cm3-min-NT386-d5.8.2-vc20.zip (I haven't yet acquired the 32bit 1.0 version, but all the others have been tested surprisingly recently.) For that matter, among: Borland 5.5 (free "beer") Metrowerks 6, 7, 8 Digital Mars (free "beer") Open Watcom (free and open source) speak up as to which, IF ANY, are desired, and what to call the target. My experiment to call everything NT386 I've decided was a failure. I'll fix that in the next release. I386_NT_DIGITALMARS, I386_NT_WATCOM, I386_NT_CODEWARRIOR, I386_NT_BORLAND ? I386_NT_DMARS, I386_NT_WAT, I386_CW I386_NT_MWCW, I386_NT_BOR??? Borland seems to still be under development but current versions are expensive. I guess I should learn the jmpbuf size of all of those and see if everyone is close and if so use the largest of them. Then it's simply a matter of ensuring we use C wrappers enough (probably already do), and getting the compiler/linker switches reasonable on the config files. - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Date: Wed, 29 Jul 2009 04:33:03 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Dependency on msvcr80.dll > > Yep, they work. Can you only use the version of VC that the compiler > was built with? > > > On 28/07/2009, at 2:07 PM, Jay K wrote: > >> >> Try these that I just made? >> >> They were built with VC 9.0: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip >> >> I didn't test them (too much combinatorial explosion -- four things >> to test!) >> >> and the readme from before: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt >> >> Olaf, there is a LOT more in the snaps directory than the snapshot- >> index lists. >> A lot. Also my archives contain more of the licenses, so many that I >> put them in a subdirectory. >> >> >> - Jay > From lists at darko.org Wed Jul 29 08:24:29 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 29 Jul 2009 08:24:29 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Message-ID: I think the latestest will suffice, since it sounds pretty easy to derive any other version from that one, and the latest VC version is freely available. The other compilers I wouldn't worry about since users probably don't exist, and if they do then they can use those products pretty easily with the VC command line tools. I use Metrowerks for instance (on the Mac) and have hacked a plugin that does most of what I want. Anyway, I'd hate to keep you from the much more interesting ARM_DARWIN :-) On 29/07/2009, at 5:16 AM, Jay K wrote: > > The compiler isn't relevant. > The libraries are. > You might as well consider them as one indivisable unit, but they > aren't quite. > I don't yet fully understand the situation. > Until/unless I/we do, we'll build a distribution per VC version. I > should have renamed the below > cm3-min-NT386-d5.8.2-vc90.zip or such but I was lazy and took > advantage of there being no other 5.8.2 currently. > > > Stay tuned (but don't hold your breath) for > cm3-min-NT386-d5.8.2-vc80.zip > > > and speak up as to which, IF ANY, of these is desired: > > cm3-min-NT386-d5.8.2-vc71.zip > cm3-min-NT386-d5.8.2-vc70.zip > cm3-min-NT386-d5.8.2-vc60.zip > cm3-min-NT386-d5.8.2-vc50.zip > cm3-min-NT386-d5.8.2-vc42.zip > cm3-min-NT386-d5.8.2-vc41.zip > cm3-min-NT386-d5.8.2-vc40.zip > cm3-min-NT386-d5.8.2-vc20.zip > (I haven't yet acquired the 32bit 1.0 version, but all the others > have been tested surprisingly recently.) > > > For that matter, among: > Borland 5.5 (free "beer") > Metrowerks 6, 7, 8 > Digital Mars (free "beer") > Open Watcom (free and open source) > > speak up as to which, IF ANY, are desired, and what to call the > target. > My experiment to call everything NT386 I've decided was a failure. > I'll fix that in the next release. > I386_NT_DIGITALMARS, I386_NT_WATCOM, I386_NT_CODEWARRIOR, > I386_NT_BORLAND ? > I386_NT_DMARS, I386_NT_WAT, I386_CW I386_NT_MWCW, I386_NT_BOR??? > Borland seems to still be under development but current versions are > expensive. > > I guess I should learn the jmpbuf size of all of those and see if > everyone is close and if so use the largest of them. Then it's > simply a matter of ensuring we use C wrappers enough (probably > already do), and getting the compiler/linker switches reasonable on > the config files. > > > - Jay > > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Wed, 29 Jul 2009 04:33:03 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Dependency on msvcr80.dll >> >> Yep, they work. Can you only use the version of VC that the compiler >> was built with? >> >> >> On 28/07/2009, at 2:07 PM, Jay K wrote: >> >>> >>> Try these that I just made? >>> >>> They were built with VC 9.0: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip >>> >>> I didn't test them (too much combinatorial explosion -- four things >>> to test!) >>> >>> and the readme from before: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt >>> >>> Olaf, there is a LOT more in the snaps directory than the snapshot- >>> index lists. >>> A lot. Also my archives contain more of the licenses, so many that I >>> put them in a subdirectory. >>> >>> >>> - Jay >> From rcoleburn at scires.com Wed Jul 29 13:14:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 07:14:57 -0400 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) Message-ID: <4A6FF67C.1E75.00D7.1@scires.com> Update on NT386 build (Windows XP, Microsoft Visual C++ Express 2008), R.Coleburn ===================================================================== Here are the errors and warnings I am seeing currently in building the minimal installation: --- processing package "m3-libs\libm3" --- --- building in NT386 --- "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) 1 warning encountered Here is a list of all packages that I am building: m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-sys\windowsResources m3-libs\patternmatching m3-libs\sysutils m3-libs\unittest m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3staloneback m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3scanner m3-sys\m3tools m3-sys\m3cgcat m3-sys\m3cggen m3-sys\m3gdb m3-tools\m3bundle m3-sys\mklib m3-sys\fix_nl m3-sys\libdump m3-libs\arithmetic m3-libs\unittest-numeric m3-libs\bitvector m3-libs\digraph m3-libs\parseparams m3-libs\realgeometry m3-libs\set m3-libs\slisp m3-libs\sortedtableextras m3-libs\table-list m3-libs\tempfiles m3-libs\tcl m3-comm\tcp m3-sys\cm3ide m3-comm\udp m3-libs\libsio m3-libs\libbuf m3-libs\debug m3-libs\listfuncs m3-libs\embutils m3-libs\m3tk-misc m3-www\http m3-libs\binIO m3-libs\commandrw m3-comm\tapi m3-comm\serial m3-tools\m3tk m3-tools\mtex m3-tools\m3totex m3-tools\m3tohtml m3-tools\m3scan m3-tools\m3markup m3-tools\m3browser m3-tools\cmpdir m3-tools\cmpfp m3-tools\dirfp m3-tools\uniq m3-comm\netobj m3-comm\netobjd m3-comm\stubgen m3-comm\events m3-comm\rdwr m3-comm\sharedobj m3-comm\sharedobjgen m3-db\odbc m3-db\postgres95 m3-db\db m3-db\smalldb m3-db\stablegen m3-db\stable m3-ui\X11R4 m3-ui\ui m3-ui\PEX m3-ui\vbtkit m3-ui\cmvbt m3-ui\jvideo m3-ui\videovbt m3-www\web m3-www\proxy m3-ui\formsvbtpixmaps m3-ui\formsvbt m3-ui\formsview m3-ui\formsedit m3-ui\codeview m3-tools\cvsup\suplib m3-tools\cvsup\client m3-tools\cvsup\server m3-tools\cvsup\cvpasswd m3-ui\mg m3-ui\mgkit m3-ui\opengl m3-ui\anim3D m3-ui\zeus m3-ui\m3zume m3-obliq\synloc m3-obliq\synex m3-obliq\metasyn m3-obliq\obliqrt m3-obliq\obliqparse m3-obliq\obliqprint m3-obliq\obliq m3-obliq\obliqlibemb m3-obliq\obliqlibm3 m3-obliq\obliqlibui m3-obliq\obliqlibanim m3-obliq\obliqsrvstd m3-obliq\obliqsrvui m3-obliq\obliqbinmin m3-obliq\obliqbinstd m3-obliq\obliqbinui m3-obliq\obliqbinanim m3-obliq\obliqlib3D m3-obliq\visualobliq m3-obliq\vocgi m3-obliq\voquery m3-obliq\vorun m3-ui\webvbt m3-tools\recordheap m3-tools\rehearsecode m3-tools\replayheap m3-tools\showheap m3-tools\shownew m3-tools\showthread m3-ui\juno-2\juno-app\pkl-fonts m3-ui\juno-2\juno-machine m3-ui\juno-2\juno-compiler m3-ui\juno-2\juno-app m3-demo\cube m3-demo\calculator m3-demo\fisheye m3-demo\mentor caltech-parser\cit_common caltech-parser\m3tmplhack caltech-parser\cit_util caltech-parser\term m3-libs\deepcopy caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\hack caltech-parser\m3browserhack caltech-parser\parserlib\ktoklib caltech-parser\parserlib\klexlib caltech-parser\parserlib\kyacclib caltech-parser\parserlib\ktok caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib caltech-parser\parserlib\parserlib\test m3-tools\pp m3-tools\kate m3-libs\sgml m3-www\deckscape m3-www\webscape m3-www\webcat m3-ui\bicycle m3-games\badbricks m3-games\columns m3-games\fours m3-games\maze m3-games\solitaire m3-games\tetris ---END-of-List--- Here are the errors and warnings I am seeing currently in building all the packages listed above: --- processing package "m3-sys\m3cc" --- --- building in NT386 --- ignoring ..\src\m3overrides _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MA KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap -disable-intl -di sable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages =m3cg -enable-targets=all -disable-dependency-tracking -disable-fixincludes -dis able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/cm3/Sandbox /cm3/m3-sys/m3cc/src/../NT386/_m3.log 'chmod' is not recognized as an internal or external command, operable program or batch file. 'sh' is not recognized as an internal or external command, operable program or batch file. "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake runtime error: exit 1: sh -ec ./_m3000.sh --procedure-- -line- -file--- exec -- m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args Fatal Error: package build failed --- processing package "m3-libs\libm3" --- --- building in NT386 --- "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) 1 warning encountered --- processing package "m3-sys\cm3" --- --- building in NT386 --- ignoring ..\src\m3overrides missing CM3_VERSION_NUMBER will read version file missing CM3_VERSION_TEXT will read version file missing CM3_LAST_CHANGED will read version file --- processing package "m3-sys\m3gdb" --- nothing attempts to build for this package --- processing package "m3-sys\mklib" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) (UNALIGNED) 1 warning encountered --- processing package "m3-db\postgres95" --- nothing attempts to build for this package --- processing package "m3-ui\X11R4" --- nothing attempts to build for this package --- processing package "m3-ui\PEX" --- nothing attempts to build for this package --- processing package "m3-tools\cvsup\suplib" --- --- processing package "m3-tools\cvsup\client" --- --- processing package "m3-tools\cvsup\server" --- --- processing package "m3-tools\cvsup\cvpasswd" --- nothing attempts to build for these packages --- processing package "m3-ui\anim3D" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Win_OpenGL_Base.m3 "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception is never raised: GraphicsBase.Failure "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: potentially unhandled exception: GraphicsBase.Failure 2 warnings encountered --- processing package "m3-obliq\obliqrt" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling ObValueCB.i3 "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) 1 warning encountered new source -> compiling ObValueCBProxy.i3 "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) 1 warning encountered new source -> compiling ObValueSO.m3 "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) 1 warning encountered new exporters -> recompiling ObValueCBProxy.i3 "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) 1 warning encountered --- processing package "caltech-parser\cit_common" --- --- building in NT386 --- ignoring ..\src\m3overrides unsupported m3_option value: "-X2 at -pg@" unsupported m3_option value: "-g" --- processing package "m3-libs\deepcopy" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling DeepCopy.m3 "..\src\DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory "..\src\DeepCopy.m3", line 61: warning: potentially unhandled exception: "..\src\DeepCopy.m3", line 97: warning: exception is never raised: 3 warnings encountered --- processing package "caltech-parser\parserlib\klexlib" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RegExpTok.m3 "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered --- processing package "caltech-parser\parserlib\parserlib\test" --- --- building in NT386 --- ignoring ..\src\m3overrides C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed --- processing package "m3-tools\pp" --- nothing attempts to build for this package --- processing package "m3-tools\kate" --- --- building in NT386 --- KDESHARE not found; please define it! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jul 29 13:30:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 07:30:25 -0400 Subject: [M3devel] prelim results on Vista Message-ID: <4A6FFA1C.1E75.00D7.1@scires.com> Jay: I tried building on Vista using the approach I outlined earlier, taking into account the config stuff you relayed to me. Thanks. I started with your d5.8.2 minimal binary install, fixed up the config stuff, and built the "min" packages, twice over. I succeeded in building the minimal installation (no fatal errors reported). Then, when trying to build everything, I ran into problems. See the list below. The first package to run into problems (aside from m3cc, which seems to be expected to fail on Windows) is m3-libs\sysutils. The errors stem from a missing Utypes interface. See below: new source -> compiling System.i3 "..\src\System.i3", line 40: unable to find interface (Utypes) "..\src\System.i3", line 37: symbol not exported (Utypes.pid_t) Any ideas on how to resolve? --Randy Coleburn ERROR LOG SUMMARY: ----------------- WARNING: Errors in package m3-sys\m3cc for -build WARNING: Errors in package m3-libs\sysutils for -build WARNING: Errors in package m3-libs\sysutils for -ship WARNING: Errors in package m3-sys\m3middle for -build WARNING: Errors in package m3-sys\m3objfile for -build WARNING: Errors in package m3-sys\m3linker for -build WARNING: Errors in package m3-sys\m3back for -build WARNING: Errors in package m3-sys\m3staloneback for -build WARNING: Errors in package m3-sys\m3front for -build WARNING: Errors in package m3-sys\m3quake for -build WARNING: Errors in package m3-sys\cm3 for -build WARNING: Errors in package m3-sys\m3tools for -build WARNING: Errors in package m3-sys\m3cgcat for -build WARNING: Errors in package m3-sys\m3cggen for -build WARNING: Errors in package m3-sys\mklib for -build WARNING: Errors in package m3-sys\libdump for -build WARNING: Errors in package m3-sys\cm3ide for -build WARNING: Errors in package m3-www\http for -build WARNING: Errors in package m3-tools\m3tohtml for -build WARNING: Errors in package m3-tools\m3browser for -build WARNING: Errors in package m3-www\proxy for -build WARNING: Errors in package m3-obliq\obliqrt for -build WARNING: Errors in package m3-obliq\obliqparse for -build WARNING: Errors in package m3-obliq\obliqprint for -build WARNING: Errors in package m3-obliq\obliq for -build WARNING: Errors in package m3-obliq\obliqlibemb for -build WARNING: Errors in package m3-obliq\obliqlibm3 for -build WARNING: Errors in package m3-obliq\obliqlibui for -build WARNING: Errors in package m3-obliq\obliqlibanim for -build WARNING: Errors in package m3-obliq\obliqsrvstd for -build WARNING: Errors in package m3-obliq\obliqsrvui for -build WARNING: Errors in package m3-obliq\obliqbinmin for -build WARNING: Errors in package m3-obliq\obliqbinstd for -build WARNING: Errors in package m3-obliq\obliqbinui for -build WARNING: Errors in package m3-obliq\obliqbinanim for -build WARNING: Errors in package m3-obliq\obliqlib3D for -build WARNING: Errors in package m3-obliq\visualobliq for -build WARNING: Errors in package m3-obliq\vocgi for -build WARNING: Errors in package m3-obliq\vorun for -build WARNING: Errors in package m3-ui\webvbt for -build WARNING: Errors in package m3-demo\mentor for -build WARNING: Errors in package caltech-parser\parserlib\parserlib\test for -build WARNING: Errors in package m3-libs\sgml for -build WARNING: Errors in package m3-www\deckscape for -build WARNING: Errors in package m3-www\webscape for -build WARNING: Errors in package m3-www\webcat for -build ---END-of-List--- ===END do-cm3=== C:\cm3\Sandbox\scripts\win>cd ..\..\m3-libs\sysutils C:\cm3\Sandbox\m3-libs\sysutils>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling System.i3 "..\src\System.i3", line 40: unable to find interface (Utypes) "..\src\System.i3", line 37: symbol not exported (Utypes.pid_t) 2 errors encountered new source -> compiling System.m3 "..\src\System.m3", line 27: imported interface contains errors (System) 1 error encountered new source -> compiling Confirmation.m3 "..\src\Confirmation.m3", line 5: imported interface contains errors (System) 1 error encountered new source -> compiling ConnectRdWr.m3 "..\src\ConnectRdWr.m3", line 6: imported interface contains errors (System) 1 error encountered new source -> compiling SystemWin32.m3 "..\src\WIN32\SystemWin32.m3", line 27: imported interface contains errors (System) 1 error encountered compilation failed => not building library "sysutils.lib" Fatal Error: package build failed CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 29 13:28:54 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 29 Jul 2009 04:28:54 -0700 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) In-Reply-To: <4A6FF67C.1E75.00D7.1@scires.com> References: <4A6FF67C.1E75.00D7.1@scires.com> Message-ID: Not bad! - Jay (phone) On Jul 29, 2009, at 4:14 AM, "Randy Coleburn" wrote: > Update on NT386 build (Windows XP, Microsoft Visual C++ Express > 2008), R.Coleburn > ===================================================================== > > Here are the errors and warnings I am seeing currently in building > the minimal installation: > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used > (CheckInt32) > 1 warning encountered > > > > Here is a list of all packages that I am building: > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-sys\windowsResources > m3-libs\patternmatching > m3-libs\sysutils > m3-libs\unittest > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3staloneback > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\m3scanner > m3-sys\m3tools > m3-sys\m3cgcat > m3-sys\m3cggen > m3-sys\m3gdb > m3-tools\m3bundle > m3-sys\mklib > m3-sys\fix_nl > m3-sys\libdump > m3-libs\arithmetic > m3-libs\unittest-numeric > m3-libs\bitvector > m3-libs\digraph > m3-libs\parseparams > m3-libs\realgeometry > m3-libs\set > m3-libs\slisp > m3-libs\sortedtableextras > m3-libs\table-list > m3-libs\tempfiles > m3-libs\tcl > m3-comm\tcp > m3-sys\cm3ide > m3-comm\udp > m3-libs\libsio > m3-libs\libbuf > m3-libs\debug > m3-libs\listfuncs > m3-libs\embutils > m3-libs\m3tk-misc > m3-www\http > m3-libs\binIO > m3-libs\commandrw > m3-comm\tapi > m3-comm\serial > m3-tools\m3tk > m3-tools\mtex > m3-tools\m3totex > m3-tools\m3tohtml > m3-tools\m3scan > m3-tools\m3markup > m3-tools\m3browser > m3-tools\cmpdir > m3-tools\cmpfp > m3-tools\dirfp > m3-tools\uniq > m3-comm\netobj > m3-comm\netobjd > m3-comm\stubgen > m3-comm\events > m3-comm\rdwr > m3-comm\sharedobj > m3-comm\sharedobjgen > m3-db\odbc > m3-db\postgres95 > m3-db\db > m3-db\smalldb > m3-db\stablegen > m3-db\stable > m3-ui\X11R4 > m3-ui\ui > m3-ui\PEX > m3-ui\vbtkit > m3-ui\cmvbt > m3-ui\jvideo > m3-ui\videovbt > m3-www\web > m3-www\proxy > m3-ui\formsvbtpixmaps > m3-ui\formsvbt > m3-ui\formsview > m3-ui\formsedit > m3-ui\codeview > m3-tools\cvsup\suplib > m3-tools\cvsup\client > m3-tools\cvsup\server > m3-tools\cvsup\cvpasswd > m3-ui\mg > m3-ui\mgkit > m3-ui\opengl > m3-ui\anim3D > m3-ui\zeus > m3-ui\m3zume > m3-obliq\synloc > m3-obliq\synex > m3-obliq\metasyn > m3-obliq\obliqrt > m3-obliq\obliqparse > m3-obliq\obliqprint > m3-obliq\obliq > m3-obliq\obliqlibemb > m3-obliq\obliqlibm3 > m3-obliq\obliqlibui > m3-obliq\obliqlibanim > m3-obliq\obliqsrvstd > m3-obliq\obliqsrvui > m3-obliq\obliqbinmin > m3-obliq\obliqbinstd > m3-obliq\obliqbinui > m3-obliq\obliqbinanim > m3-obliq\obliqlib3D > m3-obliq\visualobliq > m3-obliq\vocgi > m3-obliq\voquery > m3-obliq\vorun > m3-ui\webvbt > m3-tools\recordheap > m3-tools\rehearsecode > m3-tools\replayheap > m3-tools\showheap > m3-tools\shownew > m3-tools\showthread > m3-ui\juno-2\juno-app\pkl-fonts > m3-ui\juno-2\juno-machine > m3-ui\juno-2\juno-compiler > m3-ui\juno-2\juno-app > m3-demo\cube > m3-demo\calculator > m3-demo\fisheye > m3-demo\mentor > caltech-parser\cit_common > caltech-parser\m3tmplhack > caltech-parser\cit_util > caltech-parser\term > m3-libs\deepcopy > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\hack > caltech-parser\m3browserhack > caltech-parser\parserlib\ktoklib > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\kyacclib > caltech-parser\parserlib\ktok > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib > caltech-parser\parserlib\parserlib\test > m3-tools\pp > m3-tools\kate > m3-libs\sgml > m3-www\deckscape > m3-www\webscape > m3-www\webcat > m3-ui\bicycle > m3-games\badbricks > m3-games\columns > m3-games\fours > m3-games\maze > m3-games\solitaire > m3-games\tetris > ---END-of-List--- > > > > Here are the errors and warnings I am seeing currently in building > all the packages listed above: > > --- processing package "m3-sys\m3cc" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch > lex.yy.c' MA > KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap - > disable-intl -di > sable-libgomp -disable-libmudflap -disable-libssp -disable-nls - > enable-languages > =m3cg -enable-targets=all -disable-dependency-tracking -disable- > fixincludes -dis > able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/ > cm3/Sandbox > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > 'chmod' is not recognized as an internal or external command, > operable program or batch file. > 'sh' is not recognized as an internal or external command, > operable program or batch file. > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake > runtime error: > exit 1: sh -ec ./_m3000.sh > --procedure-- -line- -file--- > exec -- > m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc > \NT386\m3make.args > Fatal Error: package build failed > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used > (CheckInt32) > 1 warning encountered > > > --- processing package "m3-sys\cm3" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > --- processing package "m3-sys\m3gdb" --- > nothing attempts to build for this package > > > --- processing package "m3-sys\mklib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Main.m3 > "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) > (UNALIGNED) > 1 warning encountered > > > --- processing package "m3-db\postgres95" --- > nothing attempts to build for this package > > > --- processing package "m3-ui\X11R4" --- > nothing attempts to build for this package > > > --- processing package "m3-ui\PEX" --- > nothing attempts to build for this package > > > --- processing package "m3-tools\cvsup\suplib" --- > --- processing package "m3-tools\cvsup\client" --- > --- processing package "m3-tools\cvsup\server" --- > --- processing package "m3-tools\cvsup\cvpasswd" --- > nothing attempts to build for these packages > > > --- processing package "m3-ui\anim3D" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Win_OpenGL_Base.m3 > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception > is never raised: GraphicsBase.Failure > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: > potentially unhandled exception: GraphicsBase.Failure > 2 warnings encountered > > > --- processing package "m3-obliq\obliqrt" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling ObValueCB.i3 > "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueSO.m3 > "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) > 1 warning encountered > new exporters -> recompiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > > > --- processing package "caltech-parser\cit_common" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > unsupported m3_option value: "-X2 at -pg@" > unsupported m3_option value: "-g" > > > --- processing package "m3-libs\deepcopy" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling DeepCopy.m3 > "..\src\DeepCopy.m3", line 56: warning: potentially unhandled > exception: RTAllocator.OutOfMemory > "..\src\DeepCopy.m3", line 61: warning: potentially unhandled > exception: > "..\src\DeepCopy.m3", line 97: warning: exception is never raised: > > 3 warnings encountered > > > --- processing package "caltech-parser\parserlib\klexlib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling RegExpTok.m3 > "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled > exception: RTAllocator.OutOfMemory > 1 warning encountered > > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src > \Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime > error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok > \NT386\ktok ..\src\Calc.t -o CalcTok.i3 > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\NT386\m3make.args > Fatal Error: package build failed > > > --- processing package "m3-tools\pp" --- > nothing attempts to build for this package > > > --- processing package "m3-tools\kate" --- > --- building in NT386 --- > KDESHARE not found; please define it! > > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 29 14:06:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 14:06:46 +0200 Subject: [M3devel] Release engineering / OpenBSD status Message-ID: <20090729140646.2o9p3lcz4gc404s0@mail.elegosoft.com> Finally all relevant builds and tests have succeeded on OpenBSD in Hudson, too. See http://hudson.modula3.com:8080/view/I386_OPENBSD/ There are several package build/test failures though: http://hudson.modula3.com:8080/view/I386_OPENBSD/job/cm3-test-all-pkgs-I386_OPENBSD/lastBuild/testReport/ Some of these might be expected (no DB installation and other missing pre-requisites), but if anybody doesn't know how to spend his/her time, s/he might have a look at these (and fix them if possible). There are also 16 failures in m3-sys/m3tests: http://hudson.modula3.com:8080/view/I386_OPENBSD/job/cm3-test-m3tests-I386_OPENBSD/ In general everything looks much better than some days ago; the regression tests finally seem to stabilize. The failures currently visible in Hudson are all master/slave communication problems, and there's not one build red in the tinderbox :-) I think we should be able to build packages soon. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 29 14:27:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 14:27:27 +0200 Subject: [M3devel] M3devel Digest, Vol 33, Issue 104 In-Reply-To: <28748.61011.qm@web56806.mail.re3.yahoo.com> References: <28748.61011.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090729142727.296t56l5u9wc0sg8@mail.elegosoft.com> Hi Peter, thanks for your encouragement. Regression builds look much better today, I think we may be able to have RC2 packages at the weekend. Though I'll have to attend to some other business then, too, like mawing the lawn in the garden ;-) I hope I'll find the time to work on your suggestions for the web presentation then, too. As for the Debian packages you've built, we should definitely link them on the release pages. But I doubt that I'll have time to test them. I trust that others will do that before the release though. Will your web server be able to manage several downloads, or should we copy them over to birch (which is usually heavily loaded most of the time), too? Olaf Quoting Peter Eiserloh : > Hi Olaf, > > I just wanted to say thank you! You have been doing a > great job. A compiler and development environment such > as CM3 is a very large software suite, and to coordinate > a software release is never an easy job. > > Sure the web pages can use some sprucing up, big deal! > Like you said, all the web pages are in the CVS repo, any > one with write access to the repo could change them. > > It may seem like there is a lot of complaining, and it is, > but what has everyone jazzed up at the moment (okay last > few months), is that shortly, all the work we have been > doing will be seeing a much larger audience, and we want > our favorite project to look its best. > > What we all should remember is that we all have real lives, > away from the computer and modula-3. None of us has enough > time to do _everything_ we want. > > BTW: I just wanted bring your attention to my latest build > of Debian packages for AMD64_LINUX on "lenny". I built it > today from cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. > > http://www.eiserloh.org/mirrors/modula3/ > > If you have a Debian-lenn-AM64 machine, could you try it > out. Maybe, even download the source package, and try > building it yourself. The source package should work with > any architecture supported by Debian. > > Please comment on any improvements I can make to these > debian packages. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > >> Date: Mon, 27 Jul 2009 22:49:26 +0200 >> From: Olaf Wagner >> Subject: Re: [M3devel] bad web pages > It will also be the >> last time that I coordinate a CM3 release. Everyone around >> me is already complaining :-( >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 19:42:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 17:42:22 +0000 Subject: [M3devel] unused warning isn't transitive Message-ID: TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; (* We need v to be inside a record. Otherwise, the language would allow a compiler to actually allocate more than the BITS 32 for a value of type Swap.Int32. *) VAR Int32RecVar : Int32Rec; VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); Compiler complains that CheckInt32 isn't used. It should also perhaps mention Int32RecVar therefore. - Jay From jay.krell at cornell.edu Wed Jul 29 20:18:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 18:18:30 +0000 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) In-Reply-To: References: <4A6FF67C.1E75.00D7.1@scires.com> Message-ID: (formatting possibly all messed up sorry) --- processing package "m3-sys\cm3" --- --- building in NT386 --- ignoring ..\src\m3overrides missing CM3_VERSION_NUMBER will read version file missing CM3_VERSION_TEXT will read version file missing CM3_LAST_CHANGED will read version file This is arguably a failing of your .cmd. The other .sh/.py/.cmd define these. Perhaps we should always do it in the m3makefile, nowhere else, and don't warn? Or maybe it is supposed to be fixed for the entire build? Or maybe Olaf just likes to write non portable .sh, in scripts, instead of in m3makefile? (where he can still write non portable .sh, but I have to port it, either way, difference is whether or not it gets written twice or four times, twice is Posix and Win32 in m3makefile, four times is Olaf's .sh, my .py, possibly maybe my .cmd, and your .cmd) Try the .py. Tell me what errors you get. Please. There are contradictory principles at work here: reduce dependencies don't duplicate work We are duplicating work. And I might continue to -- I might rewrite more of Olaf's .sh in .py. But my argument is that it is then more portable and the duplication can then be stopped. (Granted there are sticking points, like MIPS64_OPENBSD possibly and I386_MSDOS possibly, but sh's portability is also overstated, e.g. Solaris..) You can try my .cmd too, but I'd really like to know why the Python doesn't work for you. The .sh, .py, my .cmd, and indirectly the m3makefile read the scripts/version file. Which btw should maybe be at the root? Maybe. It depends on if you feel "scripts" are "official" or merely "convenience". And if "version" is "official" -- don't mix "official" with "convenience"? Not a big deal. Many of the warnings are in generated code, which is partly why I've long ignored them. Plus that I'm lazy. We can try putting in in the generated code. I just hope the compiler isn't a stickler then and complains that sometimes there is nothing to not warn about (like when you say but use it; geez, maybe my intent was, I may or may not use, just shut up either way?) I'll see what I can do, but none or almost none of this is Windows specific. Nobody seems to care much. That unaligned thing is different. - I thought it didn't warn on NT, just others. It possibly needs to be honored on all. - The Modula-3 language is difficient here in general. We need to be able to state alignment if we do want to "interoperate directly" with external data. Normally I say "write C wrappers" but this is a file format not a super cheap little in-memory struct. We almost need to be able to state alignments higher than we can today. I've seen stuff like: setjmp.h: gccism(alignment hgher than Modula-3 allows one to state) comment(less alignment is ok, but more is better) and Modula-3 uses less. Maybe it is yucky and not ANSI C but all the compilers have various extensions to finely control layout. Either we wrap everything up, or unpack from bytes, or copy those C features. Roughly speaking. I'll probably look into "unpack from bytes". Interfacing with the external world sometimes is ugly business and that's just tough; you can't change it. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Wed, 29 Jul 2009 04:28:54 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] update on NT386 build (Windows XP, VC 2008) > > Not bad! > > - Jay (phone) > > On Jul 29, 2009, at 4:14 AM, "Randy Coleburn"> wrote: > > > Update on NT386 build (Windows XP, Microsoft Visual C++ Express 2008), R.Coleburn > ===================================================================== > > > Here are the errors and warnings I am seeing currently in building the minimal installation: > > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) > 1 warning encountered > > > > > > > > Here is a list of all packages that I am building: > > > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-sys\windowsResources > m3-libs\patternmatching > m3-libs\sysutils > m3-libs\unittest > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3staloneback > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\m3scanner > m3-sys\m3tools > m3-sys\m3cgcat > m3-sys\m3cggen > m3-sys\m3gdb > m3-tools\m3bundle > m3-sys\mklib > m3-sys\fix_nl > m3-sys\libdump > m3-libs\arithmetic > m3-libs\unittest-numeric > m3-libs\bitvector > m3-libs\digraph > m3-libs\parseparams > m3-libs\realgeometry > m3-libs\set > m3-libs\slisp > m3-libs\sortedtableextras > m3-libs\table-list > m3-libs\tempfiles > m3-libs\tcl > m3-comm\tcp > m3-sys\cm3ide > m3-comm\udp > m3-libs\libsio > m3-libs\libbuf > m3-libs\debug > m3-libs\listfuncs > m3-libs\embutils > m3-libs\m3tk-misc > m3-www\http > m3-libs\binIO > m3-libs\commandrw > m3-comm\tapi > m3-comm\serial > m3-tools\m3tk > m3-tools\mtex > m3-tools\m3totex > m3-tools\m3tohtml > m3-tools\m3scan > m3-tools\m3markup > m3-tools\m3browser > m3-tools\cmpdir > m3-tools\cmpfp > m3-tools\dirfp > m3-tools\uniq > m3-comm\netobj > m3-comm\netobjd > m3-comm\stubgen > m3-comm\events > m3-comm\rdwr > m3-comm\sharedobj > m3-comm\sharedobjgen > m3-db\odbc > m3-db\postgres95 > m3-db\db > m3-db\smalldb > m3-db\stablegen > m3-db\stable > m3-ui\X11R4 > m3-ui\ui > m3-ui\PEX > m3-ui\vbtkit > m3-ui\cmvbt > m3-ui\jvideo > m3-ui\videovbt > m3-www\web > m3-www\proxy > m3-ui\formsvbtpixmaps > m3-ui\formsvbt > m3-ui\formsview > m3-ui\formsedit > m3-ui\codeview > m3-tools\cvsup\suplib > m3-tools\cvsup\client > m3-tools\cvsup\server > m3-tools\cvsup\cvpasswd > m3-ui\mg > m3-ui\mgkit > m3-ui\opengl > m3-ui\anim3D > m3-ui\zeus > m3-ui\m3zume > m3-obliq\synloc > m3-obliq\synex > m3-obliq\metasyn > m3-obliq\obliqrt > m3-obliq\obliqparse > m3-obliq\obliqprint > m3-obliq\obliq > m3-obliq\obliqlibemb > m3-obliq\obliqlibm3 > m3-obliq\obliqlibui > m3-obliq\obliqlibanim > m3-obliq\obliqsrvstd > m3-obliq\obliqsrvui > m3-obliq\obliqbinmin > m3-obliq\obliqbinstd > m3-obliq\obliqbinui > m3-obliq\obliqbinanim > m3-obliq\obliqlib3D > m3-obliq\visualobliq > m3-obliq\vocgi > m3-obliq\voquery > m3-obliq\vorun > m3-ui\webvbt > m3-tools\recordheap > m3-tools\rehearsecode > m3-tools\replayheap > m3-tools\showheap > m3-tools\shownew > m3-tools\showthread > m3-ui\juno-2\juno-app\pkl-fonts > m3-ui\juno-2\juno-machine > m3-ui\juno-2\juno-compiler > m3-ui\juno-2\juno-app > m3-demo\cube > m3-demo\calculator > m3-demo\fisheye > m3-demo\mentor > caltech-parser\cit_common > caltech-parser\m3tmplhack > caltech-parser\cit_util > caltech-parser\term > m3-libs\deepcopy > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\hack > caltech-parser\m3browserhack > caltech-parser\parserlib\ktoklib > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\kyacclib > caltech-parser\parserlib\ktok > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib > caltech-parser\parserlib\parserlib\test > m3-tools\pp > m3-tools\kate > m3-libs\sgml > m3-www\deckscape > m3-www\webscape > m3-www\webcat > m3-ui\bicycle > m3-games\badbricks > m3-games\columns > m3-games\fours > m3-games\maze > m3-games\solitaire > m3-games\tetris > ---END-of-List--- > > > > > > > > Here are the errors and warnings I am seeing currently in building all the packages listed above: > > > > --- processing package "m3-sys\m3cc" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MA > KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap -disable-intl -di > sable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages > =m3cg -enable-targets=all -disable-dependency-tracking -disable-fixincludes -dis > able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/cm3/Sandbox > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > 'chmod' is not recognized as an internal or external command, > operable program or batch file. > 'sh' is not recognized as an internal or external command, > operable program or batch file. > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake runtime error: > exit 1: sh -ec ./_m3000.sh > --procedure-- -line- -file--- > exec -- > m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args > Fatal Error: package build failed > > > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) > 1 warning encountered > > > > > --- processing package "m3-sys\cm3" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > > > --- processing package "m3-sys\m3gdb" --- > nothing attempts to build for this package > > > > > --- processing package "m3-sys\mklib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Main.m3 > "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) (UNALIGNED) > 1 warning encountered > > > > > --- processing package "m3-db\postgres95" --- > nothing attempts to build for this package > > > > > --- processing package "m3-ui\X11R4" --- > nothing attempts to build for this package > > > > > --- processing package "m3-ui\PEX" --- > nothing attempts to build for this package > > > > > --- processing package "m3-tools\cvsup\suplib" --- > --- processing package "m3-tools\cvsup\client" --- > --- processing package "m3-tools\cvsup\server" --- > --- processing package "m3-tools\cvsup\cvpasswd" --- > nothing attempts to build for these packages > > > > > --- processing package "m3-ui\anim3D" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Win_OpenGL_Base.m3 > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception is never raised: GraphicsBase.Failure > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: potentially unhandled exception: GraphicsBase.Failure > 2 warnings encountered > > > > > --- processing package "m3-obliq\obliqrt" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling ObValueCB.i3 > "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueSO.m3 > "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) > 1 warning encountered > new exporters -> recompiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > > > > > --- processing package "caltech-parser\cit_common" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > unsupported m3_option value: "-X2 at -pg@" > unsupported m3_option value: "-g" > > > > > --- processing package "m3-libs\deepcopy" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling DeepCopy.m3 > "..\src\DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory > "..\src\DeepCopy.m3", line 61: warning: potentially unhandled exception: > "..\src\DeepCopy.m3", line 97: warning: exception is never raised: > 3 warnings encountered > > > > > --- processing package "caltech-parser\parserlib\klexlib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling RegExpTok.m3 > "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory > 1 warning encountered > > > > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > Fatal Error: package build failed > > > > > --- processing package "m3-tools\pp" --- > nothing attempts to build for this package > > > > > --- processing package "m3-tools\kate" --- > --- building in NT386 --- > KDESHARE not found; please define it! > > > > > Regards, > > Randy Coleburn > From wagner at elegosoft.com Wed Jul 29 20:34:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 20:34:25 +0200 Subject: [M3devel] m3cc build broken Message-ID: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> It looks as if the m3cc builds have broken after the last commit to the release branch: http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ error: ignoring ../src/m3overrides "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 292: quake runtime error: undefined variable: build_dir --procedure-- -line- -file--- m3cc_Run 292 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile include_dir 485 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile 4 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args Fatal Error: package build failed What's going on there? Why is build_dir suddenly undefined? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 21:12:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 19:12:54 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> Message-ID: sorry, fixed now, agreed it is odd, I don't understand, undid my simple seeming change - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 20:34:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3cc build broken > > It looks as if the m3cc builds have broken after the last > commit to the release branch: > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > error: > ignoring ../src/m3overrides > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 292: quake runtime error: undefined variable: > build_dir > > --procedure-- -line- -file--- > m3cc_Run 292 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > include_dir 485 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > 4 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > What's going on there? Why is build_dir suddenly undefined? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 29 21:23:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 21:23:39 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> Message-ID: <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Quoting Jay K : > sorry, fixed now, agreed it is odd, I don't understand, undid my > simple seeming change Never mind. The make-dist.sh script seems to be broken, too. Have a look at the end of http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. I guess I'll postpone package build again... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 21:58:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 19:58:04 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Message-ID: Whatever that was, can you run it again? Maybe with set -x? Which one? Searching for 'sed -e'... C:\dev2\cm3.2\scripts\boot-cm3-core.sh(30): sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-${CROSS_TARGET}/cm3cg\";" \ C:\dev2\cm3.2\scripts\find-packages.sh(23): grep /src/m3makefile | grep -v examples | grep -v _darcs | sed -e 's;/src/m3makefile$;;' | C:\dev2\cm3.2\scripts\find-packages.sh(24): sort | uniq | sed -e "s;^./;;" C:\dev2\cm3.2\scripts\find-src-dirs.sh(23): sed -e 's;/m3makefile$;;' -e 's;^;dir ;' C:\dev2\cm3.2\scripts\list-pkg-dirs.sh(39):for d in `listpkgs "$@" | sed -e "s;\$;/src;"`; do C:\dev2\cm3.2\scripts\list-pkg-dirs.sh(41):done | sed -e "s;^;${PREFIX};" C:\dev2\cm3.2\scripts\make-bin-dist-min.sh(107): sed -e ' C:\dev2\cm3.2\scripts\make-dist.sh(220): pw="`echo $p | sed -e 's;/;\\;g'`" C:\dev2\cm3.2\scripts\make-doc-dist.sh(48): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-script-dist.sh(39): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-all.sh(49): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-gnu.sh(51): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-std.sh(55): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-sys.sh(57): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-update.sh(58): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\pkginfo.sh(94): a=`echo $a | sed -e "s;^${ROOT}/;;"` C:\dev2\cm3.2\scripts\pkginfo.sh(96): a=`echo $a | sed -e '/\//!s;^;/;'` C:\dev2\cm3.2\scripts\pkginfo.sh(99): done | sed -e "s;^;${ROOT}/;" C:\dev2\cm3.2\scripts\pkginfo.sh(101): cat "$PKGSDB" | sed -e "s;^;${ROOT}/;" C:\dev2\cm3.2\scripts\pkgmap.sh(221): echo "$1" | sed -e 's/&/&/g' -e 's//\>/g' C:\dev2\cm3.2\scripts\pkgmap.sh(234): pname=`echo $1 | sed -e 's;/;-;g'` C:\dev2\cm3.2\scripts\sysinfo.sh(241): CM3ROOT="`cygpath -w ${ROOT} | sed -e 's;\\\;\\\\\\\\;g'`" C:\dev2\cm3.2\scripts\regression\defs.sh(10):TESTHOSTNAME=${TESTHOSTNAME:-`hostname | sed -e 's/\..*//'`} C:\dev2\cm3.2\scripts\regression\defs.sh(311): R=`cygpath -w $1 | sed -e 's/\\\\/\\\\\\\\\\\\\\\\/g'` C:\dev2\cm3.2\scripts\regression\defs.sh(364): pat=`echo "${WS}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(370): pat=`echo "${RLOG}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(376): pat=`echo "${M3TOUT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(381): pat=`echo "${M3TERR}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(386): pat=`echo "${M3TERR}.extract" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(392): pat=`echo "${CM3_SNAPSHOT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(398): pat=`echo "${HTML_REPORT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\tinderbox-build.sh(28):UNAME_R=`uname -r | sed -e 's/[^A-Za-z0-9_]/./g'` C:\dev2\cm3.2\scripts\regression\update_changelog.sh(16):WSPAT=`echo ${WS} | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\update_m3tests.sh(20): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_pkg_status.sh(20): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_snapshot_status.sh(27): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_snapshot_status.sh(30): sed -e "s/${FNPAT2s}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | 37 occurrence(s) have been found. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 21:23:39 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cc build broken > > Quoting Jay K : > >> sorry, fixed now, agreed it is odd, I don't understand, undid my >> simple seeming change > > Never mind. The make-dist.sh script seems to be broken, too. > Have a look at the end of > http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. > > I guess I'll postpone package build again... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 29 22:31:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 22:31:25 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Message-ID: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Quoting Jay K : > Whatever that was, can you run it again? Maybe with set -x? I hope that works. Watch http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-lastok-build-AMD64_LINUX/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 00:16:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 22:16:56 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: making install.cmd ++ chmod 755 install.sh ++ echo 'REM ---BEGIN---' ++ echo '@echo off' ++ printf 'for %%%%p in (' ++ for p in '${PKGS}' +++ echo m3-demo/cube +++ sed -e 's;/;\;g' sed: -e expression #1, char 7: unterminated `s' command I'll rewrite this later. But wait, I'll give you a preview. install.cmd or setup.cmd shall be a constant file, checked in. Next to it shall be deposited file with a name and format largely of your own chosing. Maybe even with Unix newlines. Certainly forward slashes are fine. Obviously the file would just be a list of relative paths to cd to. I have a slight preference for setup.cmd over install.cmd because setup.exe is common on Windows and install.cmd is slightly ambiguous with Unix /usr/bin/install. Or call it m3ship.cmd or m3setup.cmd or whatever. The name doesn't matter. It will be a constant file, checked in. Pick a name, stake a claim -- checkin an empty file somewhere (scripts?), have your .sh copy it to where you want (the root of the relevant tree), put your text file next to it, I'll fill in the code later. The text file likely is in the same directory as the .cmd. The name can be constant and/or it can be based on the cmd name. foo.cmd => foo.cmd.txt or foo.txt. If you really don't want two files, then do this: Grab the stub .cmd. Append your data to it. But prepend each line with something special. And have "something special" start with "@rem". What the .cmd can do is run findstr on itself. e.g: set self=%~f0 like argv[] for /f %%a in ('findstr /b /c:"@rem special marker" %self%"') do call :F1 %%a goto :eof :F1 more code goto :eof : append your data here. Odds are high that this will actually be JScript code but that's ok, you can embed it in a .cmd file and the technique of finding a file next to self or data appended to self still apply (like people do with Perl with pl2bat). Oh sorry one more suggestion -- this setup could also be written in Modula-3. Not a bad idea. If it is, I recommend NOT static linking, but instead putting m3core.dll/libm3.dll next to it, as a special case, and not having them also be in the derived directory. That optimizes the size overall. It could also likely be quake. Also not a bad idea. I can never glean from the huge usage statement if there is a way to ask cm3 to just run some quake code, or if only prepend/append contents to whatever its normally will search for.. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 22:31:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cc build broken > > Quoting Jay K : > >> Whatever that was, can you run it again? Maybe with set -x? > > I hope that works. Watch > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-lastok-build-AMD64_LINUX/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 30 01:09:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 23:09:37 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: ---------------------------------------- > From: jay > To: wagner > CC: m3devel > Subject: RE: [M3devel] m3cc build broken > Date: Wed, 29 Jul 2009 22:16:56 +0000 > > > making install.cmd > ++ chmod 755 install.sh > ++ echo 'REM ---BEGIN---' > ++ echo '@echo off' > ++ printf 'for %%%%p in (' > ++ for p in '${PKGS}' > +++ echo m3-demo/cube > +++ sed -e 's;/;\;g' > sed: -e expression #1, char 7: unterminated `s' command > > Or just remove the sed and be done. cd accepts forward slashes on Windows. C:\>cd 1/2/3/4 C:\1\2\3\4> - Jay From wagner at elegosoft.com Thu Jul 30 01:25:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 01:25:48 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: <20090730012548.0fsufbg62o0g8ow8@mail.elegosoft.com> Quoting Jay K : > > ---------------------------------------- >> From: jay >> To: wagner >> CC: m3devel >> Subject: RE: [M3devel] m3cc build broken >> Date: Wed, 29 Jul 2009 22:16:56 +0000 >> >> >> making install.cmd >> ++ chmod 755 install.sh >> ++ echo 'REM ---BEGIN---' >> ++ echo '@echo off' >> ++ printf 'for %%%%p in (' >> ++ for p in '${PKGS}' >> +++ echo m3-demo/cube >> +++ sed -e 's;/;\;g' >> sed: -e expression #1, char 7: unterminated `s' command > > Or just remove the sed and be done. > cd accepts forward slashes on Windows. Let's start with that. We can call it setup.cmd if you like. You can change the structure later. > C:\>cd 1/2/3/4 > > C:\1\2\3\4> I haven't found anything explaining the abstract method error. I'll just try to build everything manually first and see how far we get. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jul 30 01:36:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 19:36:45 -0400 Subject: [M3devel] package groups question Message-ID: <4A70A456.1E75.00D7.1@scires.com> In reviewing PkgInfo.txt, I find that the "min" group has the following 3 members: m3-win\import-libs m3-libs\m3core m3-libs\libm3 Are these really all that is needed to build the "minimal" binary distribution? I also ran across group "front" whose members are: m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\mklib What is the purpose of this group? Just in case anyone is interested, my "do-cm3.cmd" script has the capability to enumerate the package groupings. Here is what I find: C:\cm3\Sandbox\scripts\win>do-cm3 showtags all ====== --------------------------------- do-cm3, v1.07, 7/29/2009, Randy Coleburn ====== --------------------------------- CM3 ARGS = showtags PkgInfo = C:\cm3\Sandbox\scripts\pkginfo.txt Pkg Tree = C:\cm3\Sandbox\ Group = all Enumerating group tags in "C:\cm3\Sandbox\scripts\pkginfo.txt" ... ... one moment please ... Group Tags: ---------- base core front min std gui comm caltech-parser m3gnudevtool devlib tool m3gdb math m3devtool obliq webdev database anim cvsup juno demo game ---END-of-LIST--- Enumerating group "all" ... one moment please ... Packages in Group="base": ------------------------------------------------------------------------------ import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3bundle mklib bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp tapi serial ---END-of-List--- Packages in Group="core": ------------------------------------------------------------------------------ import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3front m3quake cm3 m3scanner m3tools m3bundle mklib bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp ---END-of-List--- Packages in Group="front": ------------------------------------------------------------------------------ import-libs m3cc m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 mklib ---END-of-List--- Packages in Group="min": ------------------------------------------------------------------------------ import-libs m3core libm3 ---END-of-List--- Packages in Group="std": ------------------------------------------------------------------------------ import-libs m3core libm3 windowsResources patternmatching sysutils unittest m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle mklib fix_nl libdump arithmetic unittest-numeric bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl tcp cm3ide udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO commandrw tapi serial m3tk mtex m3totex m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db smalldb stablegen stable X11R4 ui PEX vbtkit cmvbt jvideo videovbt m3-www/web m3-www/proxy formsvbtpixmaps formsvbt formsview formsedit codeview cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd mg mgkit opengl anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap shownew showthread juno-2/juno-app/pkl-fonts juno-2/juno-machine juno-2/juno-compiler juno-2/juno-app cube calculator fisheye mentor ---END-of-List--- Packages in Group="gui": ------------------------------------------------------------------------------ import-libs tcp X11R4 ui vbtkit cmvbt jvideo videovbt formsvbtpixmaps formsvbt formsview formsedit opengl webvbt kate m3-ui/bicycle ---END-of-List--- Packages in Group="comm": ------------------------------------------------------------------------------ import-libs tcp udp m3tk-misc tapi serial m3tk netobj netobjd stubgen ---END-of-List--- Packages in Group="caltech-parser": ------------------------------------------------------------------------------ import-libs cit_common m3tmplhack cit_util term paneman paneman/kemacs drawcontext drawcontext/dcpane drawcontext/kgv hack m3browserhack parserlib/ktoklib parserlib/klexlib parserlib/kyacclib parserlib/ktok parserlib/klex parserlib/kyacc parserlib/kext parserlib/parserlib parserlib/parserlib/test ---END-of-List--- Packages in Group="m3gnudevtool": ------------------------------------------------------------------------------ m3cc m3gdb ---END-of-List--- Packages in Group="devlib": ------------------------------------------------------------------------------ windowsResources udp libsio libbuf debug listfuncs m3tk-misc binIO commandrw tapi serial m3tk m3scan m3markup events rdwr deepcopy sgml ---END-of-List--- Packages in Group="tool": ------------------------------------------------------------------------------ m3staloneback m3cgcat m3cggen fix_nl libdump cmpdir cmpfp dirfp uniq ---END-of-List--- Packages in Group="m3gdb": ------------------------------------------------------------------------------ m3gdb ---END-of-List--- Packages in Group="math": ------------------------------------------------------------------------------ arithmetic unittest-numeric ---END-of-List--- Packages in Group="m3devtool": ------------------------------------------------------------------------------ cm3ide m3totex m3tohtml m3browser netobj netobjd stubgen sharedobj sharedobjgen stablegen stable formsview formsedit recordheap rehearsecode replayheap showheap shownew showthread pp ---END-of-List--- Packages in Group="obliq": ------------------------------------------------------------------------------ embutils synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim obliqlib3D visualobliq vocgi voquery vorun ---END-of-List--- Packages in Group="webdev": ------------------------------------------------------------------------------ http m3-www/web m3-www/proxy webvbt deckscape webscape webcat ---END-of-List--- Packages in Group="database": ------------------------------------------------------------------------------ odbc postgres95 db smalldb ---END-of-List--- Packages in Group="anim": ------------------------------------------------------------------------------ codeview mg mgkit anim3D zeus m3zume mentor ---END-of-List--- Packages in Group="cvsup": ------------------------------------------------------------------------------ cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd ---END-of-List--- Packages in Group="juno": ------------------------------------------------------------------------------ juno-2/juno-app/pkl-fonts juno-2/juno-machine juno-2/juno-compiler juno-2/juno-app ---END-of-List--- Packages in Group="demo": ------------------------------------------------------------------------------ cube calculator fisheye ---END-of-List--- Packages in Group="game": ------------------------------------------------------------------------------ m3-games/badbricks m3-games/columns m3-games/fours m3-games/maze m3-games/solitaire m3-games/tetris ---END-of-List--- ===END do-cm3=== C:\cm3\Sandbox\scripts\win> Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 30 02:35:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 00:35:16 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A70A456.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> Message-ID: I'm only going to answer partially for now.. > Are these really all that is needed > to build the "minimal" binary distribution? It depends on what you mean. The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows). That's it. You don't need any packages at all. You don't need m3core/libm3. I setup tinderbox a few times recently. In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far). What that lets you do is build the whole system, from the bottom of the dependency tree and on up. HISTORICALLY there have been some wrinkles here. And it made pretty good sense, I guess, to draw another line. Whether or not that will happen again, unclear. The specific wrinkles were: - Old compiler could not compile a new libm3, if new targets had been added That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler - Old compiler cannot compile m3core or libm3 that uses LONGINT. Now, I have a suspicion that these issues are not extremely rare but just somewhat rare. All compilation systems written in themselves have a circularity. The compiler depends on the compiler. Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make. Let's imagine, crazy, that all the identifiers were changed to lowercase. If "just" change the compiler, well then, you can't build the compiler. You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form. I feel like I might be missing something though. In any case..what are the scenarios? - People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith. Give these people "std" or a bunch of binary packages. These people, in the extreme impatience form, would not even like Olaf's workspace packages. - People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3. Today you give these people cm3, cm3cg, and config files. But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does. The difference in DEC SRC is that quake was written in C, so the division was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose). - Various (infinite) in between situations such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases. Think of the C programmer who uses mainly just printf and malloc. Or the C++ programmer who also uses STL. If you give a programmer m3core/libm3, they are in a similar position. - Jay ________________________________ > Date: Wed, 29 Jul 2009 19:36:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] package groups question > > > > > > > > In reviewing PkgInfo.txt, I find that the "min" group has the following 3 members: > > > m3-win\import-libs > m3-libs\m3core > m3-libs\libm3 > > > > Are these really all that is needed to build the "minimal" binary distribution? > > > > I also ran across group "front" whose members are: > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-libs\sysutils > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\mklib > > > > What is the purpose of this group? > > > > Just in case anyone is interested, my "do-cm3.cmd" script has the capability to enumerate the package groupings. Here is what I find: > > > > > C:\cm3\Sandbox\scripts\win>do-cm3 showtags all > > ====== --------------------------------- > do-cm3, v1.07, 7/29/2009, Randy Coleburn > ====== --------------------------------- > > CM3 ARGS = showtags > PkgInfo = C:\cm3\Sandbox\scripts\pkginfo.txt > Pkg Tree = C:\cm3\Sandbox\ > Group = all > > Enumerating group tags in "C:\cm3\Sandbox\scripts\pkginfo.txt" ... > ... one moment please ... > > Group Tags: > ---------- > base > core > front > min > std > gui > comm > caltech-parser > m3gnudevtool > devlib > tool > m3gdb > math > m3devtool > obliq > webdev > database > anim > cvsup > juno > demo > game > ---END-of-LIST--- > > Enumerating group "all" ... one moment please ... > > Packages in Group="base": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > m3middle > m3quake > m3scanner > m3tools > m3bundle > mklib > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcp > tapi > serial > ---END-of-List--- > > > Packages in Group="core": > ------------------------------------------------------------------------------ > import-libs > m3cc > m3core > libm3 > patternmatching > sysutils > unittest > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > m3scanner > m3tools > m3bundle > mklib > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcp > ---END-of-List--- > > > Packages in Group="front": > ------------------------------------------------------------------------------ > import-libs > m3cc > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > mklib > ---END-of-List--- > > > Packages in Group="min": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > ---END-of-List--- > > > Packages in Group="std": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > windowsResources > patternmatching > sysutils > unittest > m3middle > m3quake > m3scanner > m3tools > m3cgcat > m3cggen > m3gdb > m3bundle > mklib > fix_nl > libdump > arithmetic > unittest-numeric > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcl > tcp > cm3ide > udp > libsio > libbuf > debug > listfuncs > embutils > m3tk-misc > http > binIO > commandrw > tapi > serial > m3tk > mtex > m3totex > m3tohtml > m3scan > m3markup > m3browser > cmpdir > cmpfp > dirfp > uniq > netobj > netobjd > stubgen > events > rdwr > sharedobj > sharedobjgen > odbc > postgres95 > db > smalldb > stablegen > stable > X11R4 > ui > PEX > vbtkit > cmvbt > jvideo > videovbt > m3-www/web > m3-www/proxy > formsvbtpixmaps > formsvbt > formsview > formsedit > codeview > cvsup/suplib > cvsup/client > cvsup/server > cvsup/cvpasswd > mg > mgkit > opengl > anim3D > zeus > m3zume > synloc > synex > metasyn > obliqrt > obliqparse > obliqprint > obliq > obliqlibemb > obliqlibm3 > obliqlibui > obliqlibanim > obliqsrvstd > obliqsrvui > obliqbinmin > obliqbinstd > obliqbinui > obliqbinanim > visualobliq > vocgi > voquery > vorun > webvbt > recordheap > rehearsecode > replayheap > showheap > shownew > showthread > juno-2/juno-app/pkl-fonts > juno-2/juno-machine > juno-2/juno-compiler > juno-2/juno-app > cube > calculator > fisheye > mentor > ---END-of-List--- > > > Packages in Group="gui": > ------------------------------------------------------------------------------ > import-libs > tcp > X11R4 > ui > vbtkit > cmvbt > jvideo > videovbt > formsvbtpixmaps > formsvbt > formsview > formsedit > opengl > webvbt > kate > m3-ui/bicycle > ---END-of-List--- > > > Packages in Group="comm": > ------------------------------------------------------------------------------ > import-libs > tcp > udp > m3tk-misc > tapi > serial > m3tk > netobj > netobjd > stubgen > ---END-of-List--- > > > Packages in Group="caltech-parser": > ------------------------------------------------------------------------------ > import-libs > cit_common > m3tmplhack > cit_util > term > paneman > paneman/kemacs > drawcontext > drawcontext/dcpane > drawcontext/kgv > hack > m3browserhack > parserlib/ktoklib > parserlib/klexlib > parserlib/kyacclib > parserlib/ktok > parserlib/klex > parserlib/kyacc > parserlib/kext > parserlib/parserlib > parserlib/parserlib/test > ---END-of-List--- > > > Packages in Group="m3gnudevtool": > ------------------------------------------------------------------------------ > m3cc > m3gdb > ---END-of-List--- > > > Packages in Group="devlib": > ------------------------------------------------------------------------------ > windowsResources > udp > libsio > libbuf > debug > listfuncs > m3tk-misc > binIO > commandrw > tapi > serial > m3tk > m3scan > m3markup > events > rdwr > deepcopy > sgml > ---END-of-List--- > > > Packages in Group="tool": > ------------------------------------------------------------------------------ > m3staloneback > m3cgcat > m3cggen > fix_nl > libdump > cmpdir > cmpfp > dirfp > uniq > ---END-of-List--- > > > Packages in Group="m3gdb": > ------------------------------------------------------------------------------ > m3gdb > ---END-of-List--- > > > Packages in Group="math": > ------------------------------------------------------------------------------ > arithmetic > unittest-numeric > ---END-of-List--- > > > Packages in Group="m3devtool": > ------------------------------------------------------------------------------ > cm3ide > m3totex > m3tohtml > m3browser > netobj > netobjd > stubgen > sharedobj > sharedobjgen > stablegen > stable > formsview > formsedit > recordheap > rehearsecode > replayheap > showheap > shownew > showthread > pp > ---END-of-List--- > > > Packages in Group="obliq": > ------------------------------------------------------------------------------ > embutils > synloc > synex > metasyn > obliqrt > obliqparse > obliqprint > obliq > obliqlibemb > obliqlibm3 > obliqlibui > obliqlibanim > obliqsrvstd > obliqsrvui > obliqbinmin > obliqbinstd > obliqbinui > obliqbinanim > obliqlib3D > visualobliq > vocgi > voquery > vorun > ---END-of-List--- > > > Packages in Group="webdev": > ------------------------------------------------------------------------------ > http > m3-www/web > m3-www/proxy > webvbt > deckscape > webscape > webcat > ---END-of-List--- > > > Packages in Group="database": > ------------------------------------------------------------------------------ > odbc > postgres95 > db > smalldb > ---END-of-List--- > > > Packages in Group="anim": > ------------------------------------------------------------------------------ > codeview > mg > mgkit > anim3D > zeus > m3zume > mentor > ---END-of-List--- > > > Packages in Group="cvsup": > ------------------------------------------------------------------------------ > cvsup/suplib > cvsup/client > cvsup/server > cvsup/cvpasswd > ---END-of-List--- > > > Packages in Group="juno": > ------------------------------------------------------------------------------ > juno-2/juno-app/pkl-fonts > juno-2/juno-machine > juno-2/juno-compiler > juno-2/juno-app > ---END-of-List--- > > > Packages in Group="demo": > ------------------------------------------------------------------------------ > cube > calculator > fisheye > ---END-of-List--- > > > Packages in Group="game": > ------------------------------------------------------------------------------ > m3-games/badbricks > m3-games/columns > m3-games/fours > m3-games/maze > m3-games/solitaire > m3-games/tetris > ---END-of-List--- > > ===END do-cm3=== > > C:\cm3\Sandbox\scripts\win> > > > > > Regards, > > Randy Coleburn From rodney.m.bates at cox.net Thu Jul 30 03:57:42 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 29 Jul 2009 20:57:42 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: Message-ID: <4A70FE16.4080803@cox.net> Jay K wrote: > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record. Otherwise, the language would allow > a compiler to actually allocate more than the BITS 32 for a value of > type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > Transitive unusedness (boy, did that blow my email client spell checker's brains!) is a bigger issue than this example shows. There could be a large collection of identifiers that cyclically use each other, but no reference to the set from outside. For example, 35 mutually recursive, top-down parsing procedures that all call each other, but somebody forgot the base call to procedure "Program". Would we really want them all to come up unused, as well as everything declared inside any of them? It would take something like a strongly-connected graph components algorithm or such in the compiler. > > > - Jay > From rodney.m.bates at cox.net Thu Jul 30 03:48:36 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 29 Jul 2009 20:48:36 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: Message-ID: <4A70FBF4.9000806@cox.net> There is more wrong with this code than unused warnings. From 2.2.5 Packed types: "variables of type T that occur in records, objects, or arrays will occupy exactly n bits and be packed adjacent to the preceding field or element". (here, type T is BITS n FOR Base). The packed type has no effect when variables of T are not so enclosed. And the Int32Rec is nowhere enclosed in a record, object, or array. Perhaps the BITS 32 FOR should be moved inside the record and applied to the type of field v? Jay K wrote: > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record. Otherwise, the language would allow > a compiler to actually allocate more than the BITS 32 for a value of > type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > > > - Jay > From wagner at elegosoft.com Thu Jul 30 08:40:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 08:40:13 +0200 Subject: [M3devel] C compilation on Windows fails Message-ID: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Trying the first builds on our new Windows VM (still without Hudson), the first stop is: new source -> compiling hand.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\Common\\hand.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\Common\hand.c new source -> compiling dtoa.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\little-endian\\dtoa.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\little-endian\dtoa.c new source -> compiling libgcc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\libgcc\\libgcc.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\libgcc\libgcc.c new source -> compiling RTLinkerC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\common\\RTLinkerC.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\common\RTLinkerC.c new source -> compiling RTOSc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\WIN32\\RTOSc.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\ex_frame\\RTStackC.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\ex_frame\RTStackC.c new source -> compiling ThreadWin32C.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WIN32\\ThreadWin32C.c compile_c => 1073742133 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c compile_c => 1073742133 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c compile_c => 1073742133 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CerrnoC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CerrnoC.c compile_c => 1073742133 C compiler failed compiling: ..\src\C\Common\CerrnoC.c new source -> compiling CstdioC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c compile_c => 1073742133 C compiler failed compiling: ..\src\C\Common\CstdioC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling ThreadInternal.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** Why does the compiler always return 1073742133? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 09:26:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 07:26:42 +0000 Subject: [M3devel] unused warning isn't transitive In-Reply-To: <4A70FBF4.9000806@cox.net> References: <4A70FBF4.9000806@cox.net> Message-ID: 1) I was guessing inappropriately when I added BITS 32. I'll remove it. 2) I understand the need to have exactly sized types, certainly. I don't understand Modula-3's features here. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 20:48:36 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] unused warning isn't transitive > > There is more wrong with this code than unused warnings. > From 2.2.5 Packed types: "variables of type T that occur in > records, objects, or arrays will occupy exactly n bits and be > packed adjacent to the preceding field or element". > (here, type T is BITS n FOR Base). > > The packed type has no effect when variables of T are not > so enclosed. And the Int32Rec is nowhere enclosed in a > record, object, or array. Perhaps the BITS 32 FOR should be > moved inside the record and applied to the type of field v? > > > Jay K wrote: >> TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; >> (* We need v to be inside a record. Otherwise, the language would allow >> a compiler to actually allocate more than the BITS 32 for a value of >> type Swap.Int32. >> *) >> VAR Int32RecVar : Int32Rec; >> VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); >> >> >> Compiler complains that CheckInt32 isn't used. >> It should also perhaps mention Int32RecVar therefore. >> >> >> - Jay >> > From jay.krell at cornell.edu Thu Jul 30 09:32:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 07:32:51 +0000 Subject: [M3devel] C compilation on Windows fails In-Reply-To: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> References: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Message-ID: Peel the onion. cl Should print a banner and very short usage. If that works: echo.> foo.c cl -c foo.c echo %errorlevel% If that works: echo int main(){return 0;}> foo.c cl foo.c echo %errorlevel% .\foo.exe If that works, take a big step: cd wherever\m3-libs\m3core\NT386 cl -nologo -c ..\src\Csupport\Common\hand.c If that fails for lack of -I switches, add them as necessary. Add back the other switches. They are all reliable. - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 08:40:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] C compilation on Windows fails > > Trying the first builds on our new Windows VM (still without Hudson), > the first stop is: > > new source -> compiling hand.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\Common\\hand.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\Common\hand.c > new source -> compiling dtoa.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\little-endian\\dtoa.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\little-endian\dtoa.c > new source -> compiling libgcc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\libgcc\\libgcc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\libgcc\libgcc.c > new source -> compiling RTLinkerC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\common\\RTLinkerC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\common\RTLinkerC.c > new source -> compiling RTOSc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\WIN32\\RTOSc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c > new source -> compiling RTStackC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\ex_frame\\RTStackC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\ex_frame\RTStackC.c > new source -> compiling ThreadWin32C.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WIN32\\ThreadWin32C.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c > new source -> compiling WinNTc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\win32\WinNTc.c > new source -> compiling WinUserC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\win32\WinUserC.c > new source -> compiling CerrnoC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CerrnoC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\C\Common\CerrnoC.c > new source -> compiling CstdioC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\C\Common\CstdioC.c > new exporters -> recompiling RTHooks.i3 > new exporters -> recompiling RTAllocCnts.i3 > new exporters -> recompiling RTHeapRep.i3 > new exporters -> recompiling RTCollectorSRC.i3 > new exporters -> recompiling RTWeakRef.i3 > new exporters -> recompiling RTException.i3 > new exporters -> recompiling RTModule.i3 > new exporters -> recompiling RTProcedureSRC.i3 > new exporters -> recompiling RTTypeSRC.i3 > new exporters -> recompiling RTOS.i3 > new exporters -> recompiling Thread.i3 > new exporters -> recompiling Scheduler.i3 > new exporters -> recompiling ThreadF.i3 > new exporters -> recompiling ThreadInternal.i3 > new exporters -> recompiling Tick.i3 > new exporters -> recompiling Date.i3 > new exporters -> recompiling Text.i3 > compilation failed => not building library "m3core.lib" > Fatal Error: package build failed > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > Why does the compiler always return 1073742133? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 30 09:54:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 09:54:22 +0200 Subject: [M3devel] C compilation on Windows fails In-Reply-To: References: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Message-ID: <20090730095422.57hmgjn5ycocssog@mail.elegosoft.com> Quoting Jay K : > Peel the onion. > cl > > Should print a banner and very short usage. > If that works: > > echo.> foo.c > cl -c foo.c > echo %errorlevel% > > If that works: > > echo int main(){return 0;}> foo.c > cl foo.c > echo %errorlevel% > .\foo.exe > > If that works, take a big step: > > cd wherever\m3-libs\m3core\NT386 > cl -nologo -c ..\src\Csupport\Common\hand.c > If that fails for lack of -I switches, add them as necessary. > Add back the other switches. They are all reliable. OK. Will try that tonight (in about 10 hours -- just arrived at work)... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 10:12:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 08:12:21 +0000 Subject: [M3devel] NetBSD 5.0? Message-ID: I assume nobody cares if support for NetBSD prior to 5.0 is dropped? 5.0 was released April 29, 2009 and supports $ORIGIN. This doesn't mean much anyway, in that supporting additional systems is usually not difficult. - Jay From rodney.m.bates at cox.net Thu Jul 30 15:23:03 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 30 Jul 2009 08:23:03 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: <4A70FBF4.9000806@cox.net> Message-ID: <4A719EB7.4010500@cox.net> Jay K wrote: > 1) I was guessing inappropriately when I added BITS 32. I'll remove it. > I didn't realize you had recently added this. Wasn't there something similar from earlier? > 2) I understand the need to have exactly sized types, certainly. I don't understand Modula-3's features here. > Modula-3 packed types are often not well understood. The language is more-abstract/higher-level than many languages, and this is unfamiliar. Some things that seem to be frequently missed: 1) Packed types have no effect on the set of values representable. That comes strictly from the base type, which is the abstract part. Packed types can only force the compiler neither to allocate padding nor more bits than needed by the value set of the base type. 2) Packed types have an effect only when used as the type of a field of a record or object or as the type of elements of an array. Declaring a whole variable of a packed type doesn't do anything different from declaring it to have the base type. (Except, there are some losses to assignability, e.g., you can't directly assign between two different packed types that have the same base type.) > > > - Jay > > > > > ---------------------------------------- > >> Date: Wed, 29 Jul 2009 20:48:36 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] unused warning isn't transitive >> >> There is more wrong with this code than unused warnings. >> From 2.2.5 Packed types: "variables of type T that occur in >> records, objects, or arrays will occupy exactly n bits and be >> packed adjacent to the preceding field or element". >> (here, type T is BITS n FOR Base). >> >> The packed type has no effect when variables of T are not >> so enclosed. And the Int32Rec is nowhere enclosed in a >> record, object, or array. Perhaps the BITS 32 FOR should be >> moved inside the record and applied to the type of field v? >> >> >> Jay K wrote: >> >>> TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; >>> (* We need v to be inside a record. Otherwise, the language would allow >>> a compiler to actually allocate more than the BITS 32 for a value of >>> type Swap.Int32. >>> *) >>> VAR Int32RecVar : Int32Rec; >>> VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); >>> >>> >>> Compiler complains that CheckInt32 isn't used. >>> It should also perhaps mention Int32RecVar therefore. >>> >>> >>> - Jay >>> >>> From eiserlohpp at yahoo.com Thu Jul 30 18:15:42 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 30 Jul 2009 09:15:42 -0700 (PDT) Subject: [M3devel] m3cc build broken In-Reply-To: Message-ID: <939290.13563.qm@web56801.mail.re3.yahoo.com> The following does look broken. Remember the backslash is an escape character. So you are escaping the ";" delimitor. You need to escape the backslash. > +++ sed -e 's;/;\;g' > sed: -e expression #1, char 7: unterminated `s' command Try: sed -e 's;/;\\;g' +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Thu Jul 30 18:30:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 18:30:50 +0200 Subject: [M3devel] cl on windows Message-ID: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> kind of consistent user interface: elego at wagner ~/work/cm3 $ type cl cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) elego at wagner ~/work/cm3 $ cl elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -version elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -help elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl /help elego at wagner ~/work/cm3 $ echo $? 53 Can it do something else? Visual Studio Setup completely broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 18:33:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 18:33:29 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: <939290.13563.qm@web56801.mail.re3.yahoo.com> References: <939290.13563.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090730183329.mpy2y22tcwo008cw@mail.elegosoft.com> Quoting Peter Eiserloh : > The following does look broken. Remember the backslash is > an escape character. So you are escaping the ";" delimitor. > You need to escape the backslash. > >> +++ sed -e 's;/;\;g' >> sed: -e expression #1, char 7: unterminated `s' command > > Try: > sed -e 's;/;\\;g' It was escaped in the source, but the `fix' to remove $() broke it again: echo 'REM ---BEGIN---' echo '@echo off' printf 'for %%%%p in (' for p in ${PKGS}; do - pw=$(echo $p | sed -e 's;/;\\;g') + pw="`echo $p | sed -e 's;/;\\;g'`" printf "%s; " ${pw} done echo ') do call :ShipIt %%p' It was even tested before. Now it's completely removed, as Jay says forward slashes will just work everywhere. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Thu Jul 30 18:33:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 30 Jul 2009 09:33:58 -0700 (PDT) Subject: [M3devel] Web page experimental colors In-Reply-To: Message-ID: <442486.20009.qm@web56806.mail.re3.yahoo.com> Hi Olaf, www.eiserloh.org is my personal machine, on which I do most of my personal stuff. I have been putting things on its web server so other people can get to those public items I have made. I will probably have to get an account on birch or something. Speaking of debian packages, I am building a virtual machine for ARM_LINUX using qemu. Currently installing Debian Lenny in it. Inside which I will build set of CM3 debian packages for ARM. Following that: PPC_LINUX. Now if I could only get my "nslu2" up and running again. :-) Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Wed, 7/29/09, m3devel-request at elegosoft.com wrote: > From: m3devel-request at elegosoft.com > Subject: M3devel Digest, Vol 33, Issue 113 > To: m3devel at elegosoft.com > Date: Wednesday, July 29, 2009, 12:23 PM > Send M3devel mailing list submissions > to > ??? m3devel at elegosoft.com > > To subscribe or unsubscribe via the World Wide Web, visit > ??? https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > or, via email, send a message with subject or body 'help' > to > ??? m3devel-request at elegosoft.com > > You can reach the person managing the list at > ??? m3devel-owner at elegosoft.com > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of M3devel digest..." > > > Today's Topics: > > ???1. Re: M3devel Digest, Vol 33, Issue 104 > (Olaf Wagner) > ???2. unused warning isn't transitive (Jay > K) > ???3. Re: update on NT386 build (Windows XP, > VC 2008) (Jay K) > ???4. m3cc build broken (Olaf Wagner) > ???5. Re: m3cc build broken (Jay K) > ???6. Re: m3cc build broken (Olaf Wagner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Jul 2009 14:27:27 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 104 > To: m3devel at elegosoft.com > Message-ID: <20090729142727.296t56l5u9wc0sg8 at mail.elegosoft.com> > Content-Type: text/plain;??? > charset=UTF-8;??? > DelSp="Yes";??? format="flowed" > > Hi Peter, > > thanks for your encouragement. > Regression builds look much better today, I think we may > be > able to have RC2 packages at the weekend. Though I'll have > to attend > to some other business then, too, like mawing the lawn in > the > garden ;-) > > I hope I'll find the time to work on your suggestions for > the > web presentation then, too. > > As for the Debian packages you've built, we should > definitely > link them on the release pages. But I doubt that I'll have > time > to test them. I trust that others will do that before the > release > though. Will your web server be able to manage several > downloads, > or should we copy them over to birch (which is usually > heavily > loaded most of the time), too? > > Olaf > > Quoting Peter Eiserloh : > > > Hi Olaf, > > > > I just wanted to say thank you!? You have been > doing a > > great job.???A compiler and development > environment such > > as CM3 is a very large software suite, and to > coordinate > > a software release is never an easy job. > > > > Sure the web pages can use some sprucing up, big > deal! > > Like you said, all the web pages are in the CVS repo, > any > > one with write access to the repo could change them. > > > > It may seem like there is a lot of complaining, and it > is, > > but what has everyone jazzed up at the moment (okay > last > > few months), is that shortly, all the work we have > been > > doing will be seeing a much larger audience, and we > want > > our favorite project to look its best. > > > > What we all should remember is that we all have real > lives, > > away from the computer and modula-3.? None of us > has enough > > time to do _everything_ we want. > > > > BTW: I just wanted bring your attention to my latest > build > > of Debian packages for AMD64_LINUX on "lenny".? I > built it > > today from > cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. > > > >? ? http://www.eiserloh.org/mirrors/modula3/ > > > > If you have a Debian-lenn-AM64 machine, could you try > it > > out.? Maybe, even download the source package, > and try > > building it yourself.? The source package should > work with > > any architecture supported by Debian. > > > > Please comment on any improvements I can make to > these > > debian packages. > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? | > > > +--------------------------------------------------------+ > > > >> Date: Mon, 27 Jul 2009 22:49:26 +0200 > >> From: Olaf Wagner > >> Subject: Re: [M3devel] bad web pages > >? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? It will also be the > >> last time that I coordinate a CM3 release. > Everyone around > >> me is already complaining :-( > >> > >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Jul 2009 17:42:22 +0000 > From: Jay K > Subject: [M3devel] unused warning isn't transitive > To: m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record.? Otherwise, the > language would allow > ???a compiler to actually allocate more than > the BITS 32 for a value of > ???type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - > ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > > > - Jay > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jul 2009 18:18:30 +0000 > From: Jay K > Subject: Re: [M3devel] update on NT386 build (Windows XP, > VC 2008) > To: > Cc: m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > (formatting possibly all messed up sorry) > > > --- processing package "m3-sys\cm3" --- --- building in > NT386 --- ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > This is arguably a failing of your .cmd. The other > .sh/.py/.cmd define these. > Perhaps we should always do it in the m3makefile, nowhere > else, and don't warn? > Or maybe it is supposed to be fixed for the entire build? > Or maybe Olaf just likes to write non portable .sh, in > scripts, instead of in m3makefile? > (where he can still write non portable .sh, but I have to > port it, either way, difference is whether or not it gets > written twice or four times, > twice is Posix and Win32 in m3makefile, four times is > Olaf's .sh, my .py, possibly maybe my .cmd, and your .cmd) > > > Try the .py. Tell me what errors you get. Please. > > > There are contradictory principles at work here: > ? reduce dependencies > ? don't duplicate work > > > We are duplicating work. And I might continue to -- I might > rewrite more of Olaf's .sh in .py. But my argument is that > it is > then more portable and the duplication can then be stopped. > (Granted there are sticking points, like MIPS64_OPENBSD > possibly and > I386_MSDOS possibly, but sh's portability is also > overstated, e.g. Solaris..) > > > You can try my .cmd too, but I'd really like to know why > the Python doesn't work for you. > The .sh, .py, my .cmd, and indirectly the m3makefile read > the scripts/version file. > Which btw should maybe be at the root? Maybe. It depends on > if you feel "scripts" are "official" or merely > "convenience". > And if "version" is "official" -- don't mix "official" with > "convenience"? Not a big deal. > > > Many of the warnings are in generated code, which is partly > why I've long ignored them. Plus that I'm lazy. > We can try putting in? in the generated code. I just > hope the compiler isn't a stickler > then and complains that sometimes there is nothing to not > warn about (like when you say? but use it; > geez, maybe my intent was, I may or may not use, just shut > up either way?) > > > I'll see what I can do, but none or almost none of this is > Windows specific. Nobody seems to care much. > > > That unaligned thing is different. - I thought it didn't > warn on NT, just others. > It possibly needs to be honored on all. > ? - The Modula-3 language is difficient here in > general. > We need to be able to state alignment if we do want to > "interoperate directly" with external data. > Normally I say "write C wrappers" but this is a file format > not a super cheap little in-memory struct. > We almost need to be able to state alignments higher than > we can today. > > > I've seen stuff like: > setjmp.h: > ? gccism(alignment hgher than Modula-3 allows one to > state) > ? comment(less alignment is ok, but more is better) > > > and Modula-3 uses less. Maybe it is yucky and not ANSI C > but all the compilers have various extensions to finely > control layout. > Either we wrap everything up, or unpack from bytes, or copy > those C features. Roughly speaking. > I'll probably look into "unpack from bytes". > Interfacing with the external world sometimes is ugly > business and that's just tough; you can't change it. > > > - Jay > > > > > > > > > > > > ________________________________ > > From: jay.krell at cornell.edu > > To: rcoleburn at scires.com > > Date: Wed, 29 Jul 2009 04:28:54 -0700 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] update on NT386 build (Windows > XP, VC 2008) > > > > Not bad! > > > > - Jay (phone) > > > > On Jul 29, 2009, at 4:14 AM, "Randy Coleburn"> > wrote: > > > > > > Update on NT386 build (Windows XP, Microsoft Visual > C++ Express 2008), R.Coleburn > > > ===================================================================== > > > > > > Here are the errors and warnings I am seeing currently > in building the minimal installation: > > > > > > > > --- processing package "m3-libs\libm3" --- > > --- building in NT386 --- > > "..\src\pickle\ver2\ConvertPacking.m3", line 170: > warning: not used (CheckInt32) > > 1 warning encountered > > > > > > > > > > > > > > > > Here is a list of all packages that I am building: > > > > > > > > m3-win\import-libs > > m3-sys\m3cc > > m3-libs\m3core > > m3-libs\libm3 > > m3-sys\windowsResources > > m3-libs\patternmatching > > m3-libs\sysutils > > m3-libs\unittest > > m3-sys\m3middle > > m3-sys\m3objfile > > m3-sys\m3linker > > m3-sys\m3back > > m3-sys\m3staloneback > > m3-sys\m3front > > m3-sys\m3quake > > m3-sys\cm3 > > m3-sys\m3scanner > > m3-sys\m3tools > > m3-sys\m3cgcat > > m3-sys\m3cggen > > m3-sys\m3gdb > > m3-tools\m3bundle > > m3-sys\mklib > > m3-sys\fix_nl > > m3-sys\libdump > > m3-libs\arithmetic > > m3-libs\unittest-numeric > > m3-libs\bitvector > > m3-libs\digraph > > m3-libs\parseparams > > m3-libs\realgeometry > > m3-libs\set > > m3-libs\slisp > > m3-libs\sortedtableextras > > m3-libs\table-list > > m3-libs\tempfiles > > m3-libs\tcl > > m3-comm\tcp > > m3-sys\cm3ide > > m3-comm\udp > > m3-libs\libsio > > m3-libs\libbuf > > m3-libs\debug > > m3-libs\listfuncs > > m3-libs\embutils > > m3-libs\m3tk-misc > > m3-www\http > > m3-libs\binIO > > m3-libs\commandrw > > m3-comm\tapi > > m3-comm\serial > > m3-tools\m3tk > > m3-tools\mtex > > m3-tools\m3totex > > m3-tools\m3tohtml > > m3-tools\m3scan > > m3-tools\m3markup > > m3-tools\m3browser > > m3-tools\cmpdir > > m3-tools\cmpfp > > m3-tools\dirfp > > m3-tools\uniq > > m3-comm\netobj > > m3-comm\netobjd > > m3-comm\stubgen > > m3-comm\events > > m3-comm\rdwr > > m3-comm\sharedobj > > m3-comm\sharedobjgen > > m3-db\odbc > > m3-db\postgres95 > > m3-db\db > > m3-db\smalldb > > m3-db\stablegen > > m3-db\stable > > m3-ui\X11R4 > > m3-ui\ui > > m3-ui\PEX > > m3-ui\vbtkit > > m3-ui\cmvbt > > m3-ui\jvideo > > m3-ui\videovbt > > m3-www\web > > m3-www\proxy > > m3-ui\formsvbtpixmaps > > m3-ui\formsvbt > > m3-ui\formsview > > m3-ui\formsedit > > m3-ui\codeview > > m3-tools\cvsup\suplib > > m3-tools\cvsup\client > > m3-tools\cvsup\server > > m3-tools\cvsup\cvpasswd > > m3-ui\mg > > m3-ui\mgkit > > m3-ui\opengl > > m3-ui\anim3D > > m3-ui\zeus > > m3-ui\m3zume > > m3-obliq\synloc > > m3-obliq\synex > > m3-obliq\metasyn > > m3-obliq\obliqrt > > m3-obliq\obliqparse > > m3-obliq\obliqprint > > m3-obliq\obliq > > m3-obliq\obliqlibemb > > m3-obliq\obliqlibm3 > > m3-obliq\obliqlibui > > m3-obliq\obliqlibanim > > m3-obliq\obliqsrvstd > > m3-obliq\obliqsrvui > > m3-obliq\obliqbinmin > > m3-obliq\obliqbinstd > > m3-obliq\obliqbinui > > m3-obliq\obliqbinanim > > m3-obliq\obliqlib3D > > m3-obliq\visualobliq > > m3-obliq\vocgi > > m3-obliq\voquery > > m3-obliq\vorun > > m3-ui\webvbt > > m3-tools\recordheap > > m3-tools\rehearsecode > > m3-tools\replayheap > > m3-tools\showheap > > m3-tools\shownew > > m3-tools\showthread > > m3-ui\juno-2\juno-app\pkl-fonts > > m3-ui\juno-2\juno-machine > > m3-ui\juno-2\juno-compiler > > m3-ui\juno-2\juno-app > > m3-demo\cube > > m3-demo\calculator > > m3-demo\fisheye > > m3-demo\mentor > > caltech-parser\cit_common > > caltech-parser\m3tmplhack > > caltech-parser\cit_util > > caltech-parser\term > > m3-libs\deepcopy > > caltech-parser\paneman > > caltech-parser\paneman\kemacs > > caltech-parser\drawcontext > > caltech-parser\drawcontext\dcpane > > caltech-parser\drawcontext\kgv > > caltech-parser\hack > > caltech-parser\m3browserhack > > caltech-parser\parserlib\ktoklib > > caltech-parser\parserlib\klexlib > > caltech-parser\parserlib\kyacclib > > caltech-parser\parserlib\ktok > > caltech-parser\parserlib\klex > > caltech-parser\parserlib\kyacc > > caltech-parser\parserlib\kext > > caltech-parser\parserlib\parserlib > > caltech-parser\parserlib\parserlib\test > > m3-tools\pp > > m3-tools\kate > > m3-libs\sgml > > m3-www\deckscape > > m3-www\webscape > > m3-www\webcat > > m3-ui\bicycle > > m3-games\badbricks > > m3-games\columns > > m3-games\fours > > m3-games\maze > > m3-games\solitaire > > m3-games\tetris > > ---END-of-List--- > > > > > > > > > > > > > > > > Here are the errors and warnings I am seeing currently > in building all the packages listed above: > > > > > > > > --- processing package "m3-sys\m3cc" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MA > > KEINFO=: ../gcc/configure -srcdir=../gcc > -disable-bootstrap -disable-intl -di > > sable-libgomp -disable-libmudflap -disable-libssp > -disable-nls -enable-languages > > =m3cg -enable-targets=all -disable-dependency-tracking > -disable-fixincludes -dis > > able-libgcc -disable-decimal-float > -disable-fixed-point | tee -a C:/cm3/Sandbox > > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > > 'chmod' is not recognized as an internal or external > command, > > operable program or batch file. > > 'sh' is not recognized as an internal or external > command, > > operable program or batch file. > > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line > 385: quake runtime error: > > exit 1: sh -ec ./_m3000.sh > > --procedure-- -line- -file--- > > exec -- > > m3cc_Run 385 > C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > > include_dir 514 > C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args > > Fatal Error: package build failed > > > > > > > > > > --- processing package "m3-libs\libm3" --- > > --- building in NT386 --- > > "..\src\pickle\ver2\ConvertPacking.m3", line 170: > warning: not used (CheckInt32) > > 1 warning encountered > > > > > > > > > > --- processing package "m3-sys\cm3" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > missing CM3_VERSION_NUMBER will read version file > > missing CM3_VERSION_TEXT will read version file > > missing CM3_LAST_CHANGED will read version file > > > > > > > > > > --- processing package "m3-sys\m3gdb" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-sys\mklib" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling Main.m3 > > "..\src\Main.m3", line 28: warning: unrecognized > pragma (ignored) (UNALIGNED) > > 1 warning encountered > > > > > > > > > > --- processing package "m3-db\postgres95" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-ui\X11R4" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-ui\PEX" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-tools\cvsup\suplib" --- > > --- processing package "m3-tools\cvsup\client" --- > > --- processing package "m3-tools\cvsup\server" --- > > --- processing package "m3-tools\cvsup\cvpasswd" --- > > nothing attempts to build for these packages > > > > > > > > > > --- processing package "m3-ui\anim3D" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling Win_OpenGL_Base.m3 > > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: > warning: exception is never raised: GraphicsBase.Failure > > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: > warning: potentially unhandled exception: > GraphicsBase.Failure > > 2 warnings encountered > > > > > > > > > > --- processing package "m3-obliq\obliqrt" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling ObValueCB.i3 > > "..\NT386\ObValueCB.i3", line 9: warning: not used > (ObValueRep) > > 1 warning encountered > > new source -> compiling ObValueCBProxy.i3 > > "..\NT386\ObValueCBProxy.i3", line 9: warning: not > used (ObValueRep) > > 1 warning encountered > > new source -> compiling ObValueSO.m3 > > "..\NT386\ObValueSO.m3", line 12: warning: not used > (AtomList) > > 1 warning encountered > > new exporters -> recompiling ObValueCBProxy.i3 > > "..\NT386\ObValueCBProxy.i3", line 9: warning: not > used (ObValueRep) > > 1 warning encountered > > > > > > > > > > --- processing package "caltech-parser\cit_common" > --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > unsupported m3_option value: "-X2 at -pg@" > > unsupported m3_option value: "-g" > > > > > > > > > > --- processing package "m3-libs\deepcopy" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling DeepCopy.m3 > > "..\src\DeepCopy.m3", line 56: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > > "..\src\DeepCopy.m3", line 61: warning: potentially > unhandled exception: > > "..\src\DeepCopy.m3", line 97: warning: exception is > never raised: > > 3 warnings encountered > > > > > > > > > > --- processing package > "caltech-parser\parserlib\klexlib" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RegExpTok.m3 > > "..\NT386\RegExpTok.m3", line 41: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > > 1 warning encountered > > > > > > > > > > --- processing package > "caltech-parser\parserlib\parserlib\test" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok > ..\src\Calc.t -o CalcTok.i3 > > The system cannot find the path specified. > > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: > quake runtime error: exit 1: > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok > ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > > exec -- > > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > > include_dir 4 > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > > 4 > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > > > > > > > > > --- processing package "m3-tools\pp" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-tools\kate" --- > > --- building in NT386 --- > > KDESHARE not found; please define it! > > > > > > > > > > Regards, > > > > Randy Coleburn > > > > ------------------------------ > > Message: 4 > Date: Wed, 29 Jul 2009 20:34:25 +0200 > From: Olaf Wagner > Subject: [M3devel] m3cc build broken > To: m3devel at elegosoft.com > Message-ID: <20090729203425.wq5rkzvdc8gc8o88 at mail.elegosoft.com> > Content-Type: text/plain; charset=ISO-8859-15; > DelSp="Yes"; > ??? format="flowed" > > It looks as if the m3cc builds have broken after the last > commit to the release branch: > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > error: > ignoring ../src/m3overrides > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", > line 292: quake runtime error: undefined variable:? > build_dir > > --procedure--? -line-? -file--- > m3cc_Run? ? ? ? ? > 292??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > include_dir? ? > ???485??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > ? ? ? ? ? ? ? ? > ? ???4??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > What's going on there? Why is build_dir suddenly > undefined? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 5 > Date: Wed, 29 Jul 2009 19:12:54 +0000 > From: Jay K > Subject: Re: [M3devel] m3cc build broken > To: Olaf , > m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > sorry, fixed now, agreed it is odd, I don't understand, > undid my simple seeming change > > - Jay > > > ---------------------------------------- > > Date: Wed, 29 Jul 2009 20:34:25 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3cc build broken > > > > It looks as if the m3cc builds have broken after the > last > > commit to the release branch: > > > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > > > error: > > ignoring ../src/m3overrides > > > > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", > line 292: quake runtime error: undefined variable: > > build_dir > > > > --procedure-- -line- -file--- > > m3cc_Run 292 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > > include_dir 485 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > > 4 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > What's going on there? Why is build_dir suddenly > undefined? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner > | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 6 > Date: Wed, 29 Jul 2009 21:23:39 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] m3cc build broken > To: Jay K > Cc: m3devel > Message-ID: <20090729212339.q3a9jlwty8oc0ksk at mail.elegosoft.com> > Content-Type: text/plain;??? > charset=UTF-8;??? > DelSp="Yes";??? format="flowed" > > Quoting Jay K : > > > sorry, fixed now, agreed it is odd, I don't > understand, undid my??? > > simple seeming change > > Never mind. The make-dist.sh script seems to be broken, > too. > Have a look at the end of? > http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. > > I guess I'll postpone package build again... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > End of M3devel Digest, Vol 33, Issue 113 > **************************************** > From rcoleburn at scires.com Thu Jul 30 18:57:38 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 12:57:38 -0400 Subject: [M3devel] cl on windows In-Reply-To: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> Message-ID: <4A719845.1E75.00D7.1@scires.com> Olaf: I don't think you want to be doing this with cygwin. That would mean you are executing in a cygwin environment, not a true Windows-only environment. For the Visual Studio command line to work, you have to run the script that sets up the environment variables. From the Windows Start menu, there should be a menu tree labeled "Visual C++ 9.0 Express Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". Choosing this item from the menu will bring up a command prompt with the environment set up properly. Alternately, you can run the following command from an existing command prompt window: "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat x86" Note that the above command line assumes you have installed Visual C++ 2008 Express Edition. The paths may be different for different versions of the software. Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or cm3SetupCmdEnv.CMD), they do this all for you. Regards, Randy Coleburn >>> Olaf Wagner 7/30/2009 12:30 PM >>> kind of consistent user interface: elego at wagner ~/work/cm3 $ type cl cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) elego at wagner ~/work/cm3 $ cl elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -version elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -help elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl /help elego at wagner ~/work/cm3 $ echo $? 53 Can it do something else? Visual Studio Setup completely broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 30 19:23:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 19:23:56 +0200 Subject: [M3devel] cl on windows In-Reply-To: <4A719845.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Thanks for the answer, Randy. I had just remembered that I needed to set a number of variables. Attached is the shell script I came up with. Compilation works now without a problem. I get as far as linking: new source -> compiling WinUserC.c -> archiving m3core.lib link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 9 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** This seems to be a problem in the cm3 configuration files, right? More evidence: elego at wagner ~/work/cm3 $ (cd m3-libs/m3core; cm3 -commands -build -keep) --- building in NT386 --- cd NT386 ignoring ..\src\m3overrides rm .M3SHIP rm .M3OVERRIDES inhale m3core.m3x -> archiving m3core.lib rm m3core.lib rm m3core.lib rm m3core.lib.sa rm m3core.dll rm m3core.def rm m3core.lst rm m3core.dll.manifest rm m3core.pdb rm _m3responsefile0.txt rm _m3responsefile1.txt rm m3core.ilk rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk mklib @_m3responsefile0.txt 2>&1 > m3core.lst rm m3core.lib rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk link @_m3responsefile1.txt 2>&1 > m3core.lst link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 6 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. cd .. elego at wagner ~/work/cm3 $ cat m3-libs/m3core/NT386/_m3responsefile1.txt -nodefaultlib -debug -incremental:no -opt:ref -delayload:wsock32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll delayimp.lib -def:m3core.def -dll -out:m3core.dll -noentry hand.obj dtoa.obj libgcc.obj RTHooks.io RTHooks.mo [...lots of objects removed...] kernel32.lib msvcrt.lib Olaf PS: I don't think that just returning 53 is the correct way to remind users that some environment settings are missing though :-) Quoting Randy Coleburn : > Olaf: > > I don't think you want to be doing this with cygwin. That would mean > you are executing in a cygwin environment, not a true Windows-only > environment. > > For the Visual Studio command line to work, you have to run the script > that sets up the environment variables. From the Windows Start menu, > there should be a menu tree labeled "Visual C++ 9.0 Express > Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". > Choosing this item from the menu will bring up a command prompt with the > environment set up properly. > > Alternately, you can run the following command from an existing command > prompt window: "C:\Program Files\Microsoft Visual Studio > 9.0\VC\vcvarsall.bat x86" > > Note that the above command line assumes you have installed Visual C++ > 2008 Express Edition. The paths may be different for different versions > of the software. > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or > cm3SetupCmdEnv.CMD), they do this all for you. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 19:27:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 19:27:08 +0200 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <20090730192708.n77rrx3ta80ws88w@mail.elegosoft.com> Quoting Olaf Wagner : > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up with. Just in case somebody actually misses the promised attachment... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- # source me PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/BIN" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools" PATH="$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5" PATH="$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/VCPackages" PATH="$PATH:/cygdrive/c/Program Files//Microsoft SDKs/Windows/v6.0A/bin" PATH="$PATH:/cygdrive/c/WINDOWS/system32" PATH="$PATH:/cygdrive/c/WINDOWS" PATH="$PATH:/cygdrive/c/WINDOWS/System32/Wbem" PATH="$PATH:/cygdrive/c/Program Files/Microsoft SQL Server/90/Tools/binn/" PATH="$PATH:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/V/cygdrive/c/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools" INCLUDE='c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE' LIB='c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\lib;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB' LIBPATH='c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB' VCINSTALLDIR='c:\Program Files\Microsoft Visual Studio 9.0\VC' VSINSTALLDIR='c:\Program Files\Microsoft Visual Studio 9.0' DevEnvDir='c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE' Framework35Version='v3.5' FrameworkDir='c:\WINDOWS\Microsoft.NET\Framework' FrameworkVersion='v2.0.50727' export INCLUDE LIB LIBPATH VCINSTALLDIR VSINSTALLDIR DevEnvDir Framework35Version FrameworkDir FrameworkVersion From rcoleburn at scires.com Thu Jul 30 19:53:23 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 13:53:23 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> Message-ID: <4A71A555.1E75.00D7.1@scires.com> Jay: Your message was truncated, and provided much more info than I think I'm asking about. I simply need to know what packages have to be built, and in what order, to produce the minimal binary distribution for a given platform. In my case right now, platform is Windows XP or Vista. I had assumed, perhaps incorrectly, that "min" defines that set. But, I'm not sure. In particular, it looked like "front" might be building parts of the compiler that are needed. Or am I all wrong here, and rebuilding the compiler (i.e., using an old compiler to build a new version of itself) is a different process from building the minimal binary distribution? I also provided in my email a listing of all the group tags and the packages in each group for everyone's reference. (Sort of a sanity check on the correctness of PkgInfo.txt.) So, let me ask a concrete yes/no question, if one wanted to perform a complete cm3 installation on Windows, is the 13-step procedure outlined below correct? If not, please advise on changes needed. 1. Install Visual C++ 2008 Express Edition. 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. 8. mkdir "C:\cm3\bin\config" if it is missing 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". I know you've probably got scripts for all of this, but somewhere we need to document exactly what is required. Scripts are an expression of the requirements and they may contain bugs, so knowing what is supposed to happen, versus reading a script, is important. Regards, Randy >>> Jay K 7/29/2009 8:35 PM >>> I'm only going to answer partially for now.. > Are these really all that is needed > to build the "minimal" binary distribution? It depends on what you mean. The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows). That's it. You don't need any packages at all. You don't need m3core/libm3. I setup tinderbox a few times recently. In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far). What that lets you do is build the whole system, from the bottom of the dependency tree and on up. HISTORICALLY there have been some wrinkles here. And it made pretty good sense, I guess, to draw another line. Whether or not that will happen again, unclear. The specific wrinkles were: - Old compiler could not compile a new libm3, if new targets had been added That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler - Old compiler cannot compile m3core or libm3 that uses LONGINT. Now, I have a suspicion that these issues are not extremely rare but just somewhat rare. All compilation systems written in themselves have a circularity. The compiler depends on the compiler. Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make. Let's imagine, crazy, that all the identifiers were changed to lowercase. If "just" change the compiler, well then, you can't build the compiler. You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form. I feel like I might be missing something though. In any case..what are the scenarios? - People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith. Give these people "std" or a bunch of binary packages. These people, in the extreme impatience form, would not even like Olaf's workspace packages. - People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3. Today you give these people cm3, cm3cg, and config files. But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does. The difference in DEC SRC is that quake was written in C, so the division was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose). - Various (infinite) in between situations such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 30 21:35:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 19:35:13 +0000 Subject: [M3devel] cl on windows In-Reply-To: <4A719845.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: Cygwin is fine. Really. You can mix them. The problem is that both cl.exe and mspdb90.dll need to be in path, and VC link.exe needs to be ahead of Cygwin link.exe, or delete Cygwin link.exe. C:\Users\jay>which cl /cygdrive/c/msdev/90/VC/BIN/cl C:\Users\jay>which gcc /usr/bin/gcc C:\Users\jay>which cvs /usr/bin/cvs C:\Users\jay>gcc -v ... gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) C:\Users\jay>cvs Usage: cvs [cvs-options] command [command-options-and-arguments] ... C:\Users\jay>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] C:\Users\jay>which mspdb80.dll /cygdrive/c/msdev/90/Common7/IDE/mspdb80.dll C:\Users\jay>which link /cygdrive/c/msdev/90/VC/BIN/link - Jay ________________________________ > Date: Thu, 30 Jul 2009 12:57:38 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cl on windows > > > > > > > > Olaf: > > > > I don't think you want to be doing this with cygwin. That would mean you are executing in a cygwin environment, not a true Windows-only environment. > > > > For the Visual Studio command line to work, you have to run the script that sets up the environment variables. From the Windows Start menu, there should be a menu tree labeled "Visual C++ 9.0 Express Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". Choosing this item from the menu will bring up a command prompt with the environment set up properly. > > > > Alternately, you can run the following command from an existing command prompt window: "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat x86" > > > > Note that the above command line assumes you have installed Visual C++ 2008 Express Edition. The paths may be different for different versions of the software. > > > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or cm3SetupCmdEnv.CMD), they do this all for you. > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/30/2009 12:30 PM>>> > kind of consistent user interface: > > elego at wagner ~/work/cm3 > $ type cl > cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) > > elego at wagner ~/work/cm3 > $ cl > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl -version > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl -help > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl /help > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > Can it do something else? > Visual Studio Setup completely broken? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 30 21:48:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 19:48:38 +0000 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. Cygwin's link.exe is a synonym for ln.exe. > Attached is the shell script I came up with. Here are my mine for many environments. Of particular interest are: env\cm3\cm3.cygwin.bat env\cm3\cm3.vc90.bat env\test.bat used to work but I've deleted some of the toolsets You can see a lot of it works via composition. cm3.vc90.bat uses env\ms\vc90.bat - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 19:23:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cl on windows > > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up with. > > Compilation works now without a problem. I get as far as linking: > > new source -> compiling WinUserC.c > -> archiving m3core.lib > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 9 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > This seems to be a problem in the cm3 configuration files, right? > > More evidence: > > elego at wagner ~/work/cm3 > $ (cd m3-libs/m3core; cm3 -commands -build -keep) > --- building in NT386 --- > > cd NT386 > ignoring ..\src\m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale m3core.m3x > > -> archiving m3core.lib > rm m3core.lib > rm m3core.lib > rm m3core.lib.sa > rm m3core.dll > rm m3core.def > rm m3core.lst > rm m3core.dll.manifest > rm m3core.pdb > rm _m3responsefile0.txt > rm _m3responsefile1.txt > rm m3core.ilk > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > mklib @_m3responsefile0.txt 2>&1> m3core.lst > rm m3core.lib > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > link @_m3responsefile1.txt 2>&1> m3core.lst > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 6 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > cd .. > > elego at wagner ~/work/cm3 > $ cat m3-libs/m3core/NT386/_m3responsefile1.txt > -nodefaultlib > -debug > -incremental:no > -opt:ref > -delayload:wsock32.dll > -delayload:advapi32.dll > -delayload:gdi32.dll > -delayload:netapi32.dll > -delayload:user32.dll > -delayload:comctl32.dll > delayimp.lib > -def:m3core.def > -dll > -out:m3core.dll > -noentry > hand.obj > dtoa.obj > libgcc.obj > RTHooks.io > RTHooks.mo > [...lots of objects removed...] > kernel32.lib > msvcrt.lib > > > Olaf > > PS: I don't think that just returning 53 is the correct way to remind > users that some environment settings are missing though :-) > > Quoting Randy Coleburn : > >> Olaf: >> >> I don't think you want to be doing this with cygwin. That would mean >> you are executing in a cygwin environment, not a true Windows-only >> environment. >> >> For the Visual Studio command line to work, you have to run the script >> that sets up the environment variables. From the Windows Start menu, >> there should be a menu tree labeled "Visual C++ 9.0 Express >> Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". >> Choosing this item from the menu will bring up a command prompt with the >> environment set up properly. >> >> Alternately, you can run the following command from an existing command >> prompt window: "C:\Program Files\Microsoft Visual Studio >> 9.0\VC\vcvarsall.bat x86" >> >> Note that the above command line assumes you have installed Visual C++ >> 2008 Express Edition. The paths may be different for different versions >> of the software. >> >> Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or >> cm3SetupCmdEnv.CMD), they do this all for you. >> >> Regards, >> Randy Coleburn > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- A non-text attachment was scrubbed... Name: env.zip Type: application/x-zip-compressed Size: 63495 bytes Desc: not available URL: From jay.krell at cornell.edu Thu Jul 30 22:11:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 20:11:41 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A71A555.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> Message-ID: Randy, the short answer is: Find a goal state in a graph, which you haven't clearly done, walk that graph from the bottom up, and if there are circularities (there are, you need to have cm3 first, before you can build cm3), you need to download prebuilt files from somewhere (cm3 and mklib). Everything else is filling in the details of the goal state, discovering the circularities, and that we have the graph recorded in a redundant fashion in pkginfo.txt. The real data is the m3makefiles. longer answer: Randy, what is a "minimal" distribution? You have't defined the goal. What is "build"? You haven't defined the goal. I could just say: "Whatever you need, to build it, just download it from here." I'll define it as some arbitrary very minimal compiler and runtime set, specifically m3core and libm3. But you can have working Modula-3 programs certainly without libm3. And some Modula-3 programs will have a GUI so will want more libraries. What is "minimal"? And depending on future changes, the steps might change. Or maybe just pkginfo.txt will change. If there is no documentation and there is code, the code is the documentation. A lot of the code is declarative -- you look at the import statements in m3makefile. For given package foo, say "cm3", you walk the list of imports transitively. I'm not sure cm3 actually uses libm3 for example, and maybe it won't in the future. This is a very real point. pkginfo.txt duplicates dependency information by nature of being "in the correct order", but that information is already contained in the m3makefiles. Your questions have made me realize the redundancy we have and that we should fix it. Or, really, older cm3 did not use sysutils, but now it does. Things change. And you haven't really defined the goal. Instead of "walk pkginfo.txt in order", it should be "pick a package you want, say cm3, and build its dependency tree from the bottom up, using the m3makefiles to discover that tree, plus the PKGS file to locate packages". I'm going to make up a goal that might resemble yours and correct your instructions. > 1. Install Visual C++ 2008 Express Edition. ok. Though you don't need all of it by far. You don't need the entire IDE. > > 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. No. You don't need all of it. You only need two files -- cm3.exe and mklib.exe. Other platforms need cm3cg and don't need mklib. Except you never really need cm3cg, it falls out of the instructions -- cm3 can build it. It depends on how much you want to build vs. download. And optionally the config files. You can get them from either the source tree or download them. See, two legitimate places for things -- download from one place or another. > > > 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. No. You don't need all of it. You need, roughly, only m3-libs\m3core, m3-libs\libm3, m3-libs\sysutils, some of m3-sys. m3-sys/m3cc is needed for most platforms, but not the gcc-apple directory, that's only for iphone. > > 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" Not needed. > > 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" Not needed. > > 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. Many ways to do that. > > > 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. Multiple ways to do this but ok. > > > 8. mkdir "C:\cm3\bin\config" if it is missing ok. You can just mkdir unconditionally. > > > 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" You don't need all of it, but ok, that is what I do. > > > 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: > > INSTALL_ROOT = path() & "/.." > > include(path() & "/config/" & HOST) ok > > > 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) No. Well, it depends on the goal. Really. You already have a cm3. "min" gives you m3core and libm3. Combine that with the cm3 you already have and great, you have a slightly larger more useful set of libraries. > > > 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. NOt really. The repitition isn't doing what you say. Look at the group called "front". Which isn't completely accurate since it includes m3cc. Perhaps there should be a group compiler. But really, again, this is cm3 plus its transitive dependencies. I think maybe we need to partly ditch "groups". In paritcular, "groups" should contain useful end results and not their dependencies. m3middle doesn't belong in any group, it is just implied by cm3. Seriously. But the scripts don't currently read m3makefiles. Redoing things in cm3 would be better? > > > 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". Ok. Sort of. > > I know you've probably got scripts for all of this Yep. > Scripts are an expression of the requirements Sometimes it is the other way around. - Jay From wagner at elegosoft.com Thu Jul 30 22:16:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:16:42 +0200 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <442486.20009.qm@web56806.mail.re3.yahoo.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Olaf, > > www.eiserloh.org is my personal machine, on which I do most of my > personal stuff. I have been putting things on its web > server so other people can get to those public items I > have made. > > I will probably have to get an account on birch or something. > > Speaking of debian packages, I am building a virtual machine > for ARM_LINUX using qemu. Currently installing Debian Lenny > in it. Inside which I will build set of CM3 debian packages > for ARM. > > Following that: PPC_LINUX. > > Now if I could only get my "nslu2" up and running again. :-) Everyone known on the m3 mailing lists will easily get an ssh login to birch without problems by just sending a public ssh key to our administrators. You can use that account to commit to the M3 repository, to test and compile on birch (as long as you don't bring the machine down) and to generally look around (M3 web server, tinderbox, Hudson). We can create a staging area for new designs on the web server, too. I can also create logins on the new Hudson server for all those who are interested. Access is simply password restricted there and not really secure though. All that should be described in our web pages, too, but it's probably buried and well hidden :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 22:19:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:19:19 +0200 Subject: [M3devel] cl on windows In-Reply-To: References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: <20090730221919.j5ufrc8qroc4swog@mail.elegosoft.com> Quoting Jay K : > > Cygwin is fine. Really. You can mix them. > The problem is that both cl.exe and mspdb90.dll need to be in path, > and VC link.exe needs to be ahead of Cygwin link.exe, or delete > Cygwin link.exe. Oh my, stupid me! Wrong link command... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 22:30:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:30:37 +0200 Subject: [M3devel] cl on windows In-Reply-To: References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> Quoting Jay K : > Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. > Cygwin's link.exe is a synonym for ln.exe. One step further thanks to your hint. Now dynamic linking fails: Creating library sysutils.lib and object sysutils.exp LINK : fatal error LNK1101: incorrect MSPDB80.DLL version; recheck installation of this product As I haven't installed anything on this VM and only have ssh access, I've got no idea what/how to check. It's just a copy of a standard VM installation we have as far as I know. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 22:44:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 20:44:08 +0000 Subject: [M3devel] cl on windows In-Reply-To: <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> Message-ID: Hm. Backup. I'm not sure what's going on so I'll be more conservative. Did you install Visual C++ or copy it around? Did you set %PATH% or run the start menu shortcut that Randy suggested? Try installing rather than copying. Try the start menu shortcut, then set PATH=%PATH%;c:\cygwin\bin (or PATH=C:\cygwin\bin;%PATH% if you delete the Cygwin link.exe) Kill any mspdbsrv.exe process. Not repeatedly, but once. Did you start with my VC80 cm3 or my VC90 cm3? - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 22:30:37 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; khaeusler at elegosoft.com > Subject: Re: [M3devel] cl on windows > > Quoting Jay K : > >> Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. >> Cygwin's link.exe is a synonym for ln.exe. > > One step further thanks to your hint. Now dynamic linking fails: > > Creating library sysutils.lib and object sysutils.exp > LINK : fatal error LNK1101: incorrect MSPDB80.DLL version; recheck > installation of this product > > As I haven't installed anything on this VM and only have ssh access, > I've got no idea what/how to check. It's just a copy of a standard > VM installation we have as far as I know. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From dragisha at m3w.org Fri Jul 31 00:20:39 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 00:20:39 +0200 Subject: [M3devel] M3Config In-Reply-To: References: Message-ID: <1248992439.2801.9.camel@faramir.m3w.org> I have code reading data structure information from .M3WEB files.... And that code used M3Config for obvious things... Now when you killed it, how I am supposed (in portable way) to find these files? :) TIA, dd On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > So..I was wondering..what were the original authors thinking? > > And there was that comment about the file containing the data upon > install. > Which seemed wrong to me. > > They were probably thinking of the way 3.6 was packaged and > distributed -- everyone built the system from source, upon building > m3build/m3ship from C and m3 from assembly. > > That isn't a bad model, but we probably want both. > > There are at least three times the paths can be computed/recorded: > 1) when you build libm3 > 2) when you install libm3 > #1 and #2 may or may not be close in time and have the same result. > 3) by parsing cm3.cfg as needed > > #2 is more efficient than #3 and matches the old code, but #3 is how I > left it, probably ok. > > - Jay > -- Dragi?a Duri? From dragisha at m3w.org Fri Jul 31 00:17:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 00:17:47 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: <1248992267.2801.7.camel@faramir.m3w.org> cm3 -? ... > CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, > "make DESTDIR=" behaviour for cm3 > This is one patch I've introduced earlier and it's excellent conduit for RPM packaging scripts I develop. I am using it like this: > export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT > > ./scripts/do-pkg.sh realclean m3core libm3 > > ./scripts/do-pkg.sh buildship m3core libm3 > Please let me know if your script fails on you mentioning mkdir failure. I have workaround for it (as Jay did not accept my report as a bug). I'll put my RPM script in repository RSN. dd On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 03:27:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 01:27:23 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1248992267.2801.7.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: > I have workaround for it (as Jay did not accept my report as a bug). I believe I fixed it. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Fri, 31 Jul 2009 00:17:47 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > cm3 -? > ... >> CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, >> "make DESTDIR=" behaviour for cm3 >> > > This is one patch I've introduced earlier and it's excellent conduit for > RPM packaging scripts I develop. I am using it like this: > > >> export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT >> >> ./scripts/do-pkg.sh realclean m3core libm3 >> >> ./scripts/do-pkg.sh buildship m3core libm3 >> > > Please let me know if your script fails on you mentioning mkdir failure. > I have workaround for it (as Jay did not accept my report as a bug). > > > I'll put my RPM script in repository RSN. > > dd > > On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: >> Hi Jay, >> >> Do you know of any way to tell the build system that the >> final installation directory is located in one place, but >> that the software is to actually be shipped (temporarily) >> to a staging directory. >> >> Specifically, libm3/src/config contains a m3makefile that >> derives the M3Config interface, containing a number of >> paths to the installation root directory. >> >> This is the normal situation for most people, but I am >> installing to a temporary directory, for packaging purposes. >> The packaging software later installs the package into >> the correct location. >> >> Whenever I build the system, M3Config always contains >> the paths to my staging area. >> >> I would like some way of specifying to the build system >> that the final (or real) installation root is one thing, >> but "ship" would actually install into a different one. >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 03:30:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 01:30:04 +0000 Subject: [M3devel] M3Config In-Reply-To: <1248992439.2801.9.camel@faramir.m3w.org> References: <1248992439.2801.9.camel@faramir.m3w.org> Message-ID: It was partly unsupportable and you can trivially replace it with MxConfig. Please try that -- MxConfig. MxConfig.Get() I recall. We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 00:20:39 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config > > I have code reading data structure information from .M3WEB files.... And > that code used M3Config for obvious things... Now when you killed it, > how I am supposed (in portable way) to find these files? :) > > TIA, > dd > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: >> So..I was wondering..what were the original authors thinking? >> >> And there was that comment about the file containing the data upon >> install. >> Which seemed wrong to me. >> >> They were probably thinking of the way 3.6 was packaged and >> distributed -- everyone built the system from source, upon building >> m3build/m3ship from C and m3 from assembly. >> >> That isn't a bad model, but we probably want both. >> >> There are at least three times the paths can be computed/recorded: >> 1) when you build libm3 >> 2) when you install libm3 >> #1 and #2 may or may not be close in time and have the same result. >> 3) by parsing cm3.cfg as needed >> >> #2 is more efficient than #3 and matches the old code, but #3 is how I >> left it, probably ok. >> >> - Jay >> > -- > Dragi?a Duri? > From rcoleburn at scires.com Fri Jul 31 03:54:08 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 21:54:08 -0400 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <4A721600.1E75.00D7.1@scires.com> Olaf: Using the "do-cm3.cmd" script that I checked in, I am currently able to compile and link on both Windows XP and Vista all packages listed in PkgInfo.txt , except for the packages that have been disabled via the m3makefile for NT386. Again, I suspect your problem may be in using cygwin. I infer that you are using cygwin based on the path name below "C:\cygwin\usr\local...". Again, this is further evidence why there needs to be a distinction between a CM3 installation for Windows and one for cygwin running on Windows; and why the supporting scripts may need to be different. Of course, if Jay succeeds in getting the python scripts to be truly "portable" between the various platforms, it may cut down on the maintenance, since we won't need a different script for every platform. For now, I'm holding fast to Windows CMD because I can make it work and I don't have to install anything else to get it to work. Regards, Randy >>> Olaf Wagner 7/30/2009 1:23 PM >>> Thanks for the answer, Randy. I had just remembered that I needed to set a number of variables. Attached is the shell script I came up with. Compilation works now without a problem. I get as far as linking: new source -> compiling WinUserC.c -> archiving m3core.lib link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 9 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** This seems to be a problem in the cm3 configuration files, right? More evidence: elego at wagner ~/work/cm3 $ (cd m3-libs/m3core; cm3 -commands -build -keep) --- building in NT386 --- cd NT386 ignoring ..\src\m3overrides rm .M3SHIP rm .M3OVERRIDES inhale m3core.m3x -> archiving m3core.lib rm m3core.lib rm m3core.lib rm m3core.lib.sa rm m3core.dll rm m3core.def rm m3core.lst rm m3core.dll.manifest rm m3core.pdb rm _m3responsefile0.txt rm _m3responsefile1.txt rm m3core.ilk rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk mklib @_m3responsefile0.txt 2>&1 > m3core.lst rm m3core.lib rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk link @_m3responsefile1.txt 2>&1 > m3core.lst link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 6 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. cd .. elego at wagner ~/work/cm3 $ cat m3-libs/m3core/NT386/_m3responsefile1.txt -nodefaultlib -debug -incremental:no -opt:ref -delayload:wsock32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll delayimp.lib -def:m3core.def -dll -out:m3core.dll -noentry hand.obj dtoa.obj libgcc.obj RTHooks.io RTHooks.mo [...lots of objects removed...] kernel32.lib msvcrt.lib Olaf PS: I don't think that just returning 53 is the correct way to remind users that some environment settings are missing though :-) Quoting Randy Coleburn : > Olaf: > > I don't think you want to be doing this with cygwin. That would mean > you are executing in a cygwin environment, not a true Windows-only > environment. > > For the Visual Studio command line to work, you have to run the script > that sets up the environment variables. From the Windows Start menu, > there should be a menu tree labeled "Visual C++ 9.0 Express > Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". > Choosing this item from the menu will bring up a command prompt with the > environment set up properly. > > Alternately, you can run the following command from an existing command > prompt window: "C:\Program Files\Microsoft Visual Studio > 9.0\VC\vcvarsall.bat x86" > > Note that the above command line assumes you have installed Visual C++ > 2008 Express Edition. The paths may be different for different versions > of the software. > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or > cm3SetupCmdEnv.CMD), they do this all for you. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 06:14:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 00:14:54 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> Message-ID: <4A7236FD.1E75.00D7.1@scires.com> Jay: Thanks for your reply. I really appreciate your patience in dealing with all my questions, especially during this busy time preparing for the release. In response, I offer the following and also ask a few more questions: My use of the term "minimal" is consistent with what has been documented in the working release documentation. Namely, that "min" is the smallest distribution we plan to make available, versus "std" that contains a "standard" distribution, versus "all" that contains everything. Now as to the exact composition of "min" and "std" that is part of my question. I assumed someone (you, Olaf, Tony, ?) has defined what these mean. Further, if you look at PkgInfo.txt, it appears that these definitions are recorded there, but again back to my question as to whether these definitions are accurate, complete, what the "cm3 community" wants/expects, and whether my understanding of how they are used in the context of cm3 is indeed correct. I am well-versed in compilers and operating systems principles and design, so I don't need a lecture on these fundamentals. My line of questioning is concrete with respect to the impending cm3 release. My use of the term "build" is in the context of "cm3 -build", and to be useful, subsequently "cm3 -ship". As a software/systems engineer, I understand what you mean when you say that the code is the documentation when there is no external documentation. However, I would hope you agree that no external documentation is generally a bad thing. Hence my questions. I'm not a python code writer yet, though I'm confident I could be, given some time to learn. Thus, I can't presently rely on reading a python script as documentation. I am confident that if you, Olaf, Tony, or someone can confirm or correct my understanding of what I've posed as the way to install the "min" distribution on Windows and "build" the rest, that I can and will be able to document this process externally for others to review. We can then check scripts to see if they deviate from the documentation and make changes (to either scripts or documentation) as needed to reflect reality. You state that I have not defined the "goal." Let me attempt to make this obvious. I'm not trying to upset the apple cart here or change the way you work to achieve progress/success. My goal simply is to "understand" wrt the impending release so I can document, and so I can "do the right thing" to make this work correctly on my system. We can discuss in the future how things should change for the next release. Thanks for help with my 13-steps. I have some comments and a few more questions below. WRT #1, Yes, I know I may not need all of Visual Studio, but most users will just choose the typical installation. If we have specific minimums that need to be present, we should identify (document) those for users who choose to customize their installation. WRT #2, you have to start somewhere. If we have both "min" and "std" distributions, one can choose which to start with, but your discussion of which parts to trim out of "min" should not be left to the end user. The release team needs to establish what constitutes "min". My "opinion" is that "min" should contain only what is necessary for a working cm3 compiler, given the dependency on the platform-specific linker. Using "min" one should be able to build (cm3 -build -ship) all other packages. Anything added to "min" that isn't necessary to accomplish building the remaining packages would be considered superfluous, in my opinion. Some amount of superfluous on a given platform may be tolerable in order to reach consistency among all supported platforms regarding the composition of "min". Thus, if cm3cg is needed for "min" on some platforms, but not all, it is tolerable (IMO) to make it a standard component of "min" on all platforms. WRT #3, point taken. However, unless we have an easy way to specify and checkout only those parts of the tree relevant to a particular platform, checking out everything ensures you haven't missed something that is going to cause problems later. WRT#4, although doc may not be needed to run cm3, it is needed for folks to reference and understand cm3. This is a long-standing gripe of mine that we don't make the installation of doc part of the typical installation. The naive user new to cm3 normally expects to get some documentation. If the default is no documentation, how does the poor sap know how to get the documentation and install it? Also, cm3ide, does have links to the doc folder. If you click on these links and they are broken, the average user is going to rate cm3 as a poor product and move on to something else. Why create a problem for the new user? Give him the documentation he needs by default and let the expert user remove it if it is unwanted. I know that Critical Mass's 4.1 installation put the doc folder there. When did someone decide it wasn't appropriate for the default installation? WRT#5, examples is needed for cm3ide. Right now, my bet is that most everyone in the cm3 community doesn't know they should copy the examples folder to the root of their cm3 installation. That's because Reactor wasn't open-sourced until recently as cm3ide. Right now the only documentation about this is a README file buried in the repository and even that wouldn't be there if I hadn't put it there. Again, don't create a problem for the new user. The "typical" installation choice should install it by default. Let the expert user choose to remove it as part of a custom install if it is not wanted. WRT#6, agree. That's why I wasn't specific on how to do it, but for the newbie, it would probably be best to list at least one way. WRT#7, agree. I was just stating my interpretation of what you had communicated to me earlier about setting up config properly. WRT#8, ok, but you do get an error message if the folder exists already. WRT#9, ditto #7 WRT#11, now we are finally getting to the meat of my questions. So, if I understand you correctly, you are saying that building the "min" group of packages does not recreate for me exactly what is being published as the "min" distribution. In my view, we have a conflict of terminology here that needs to be cleaned up. So what exactly is "min" as defined in PkgInfo.txt if it doesn't represent the minimal binary install? Furthermore, if I want to use cm3 to build the sources for the compiler itself, it would seem from your comments that "min" won't do it. Which packages need to built, and in what order, to recreate cm3.exe ? Again you ask about the goal here, so let me be more explicit. Given that cm3 continues to evolve and that minimal distributions are created at unpredictable intervals, if one wants to ensure the cm3 compiler is up-to-date with the latest sources, one would want to start with some existing cm3 installation and build and ship the compiler's source package(s) along with any other packages where a dependency exists. In these instructions, I started with obtaining the latest "min" distribution, then grabbed the current source tree, so I want to proceed from this point to build a current cm3 compiler and any other requisite components to again create a "minimal" installation on my platform. From there, one can build some/all of the remaining packages. WRT#12, the repeat is due to my prior understanding. Perhaps this is incorrect, or perhaps the recent changes have made this unnecessary. But, it seems my understanding of how to rebuild cm3.exe is flawed given your response to #11. Are you saying I should use "front" to build cm3.exe? Am I the only one to whom all this is unclear? Again, we need to document for understanding. WRT#13, not sure what you mean by "sort of". What are the caveats? Regarding your comment at the end about scripts, I will respectfully choose to disagree with you and hope that we work together to improve documentation. After all, if we all get run over by a truck, what we know in our brains isn't available to others unless we've documented it somewhere. Thanks for your patience in putting up with all my questions! Thanks also for all you are doing for cm3! Regards, Randy Coleburn >>> Jay K 7/30/2009 4:11 PM >>> Randy, the short answer is: Find a goal state in a graph, which you haven't clearly done, walk that graph from the bottom up, and if there are circularities (there are, you need to have cm3 first, before you can build cm3), you need to download prebuilt files from somewhere (cm3 and mklib). Everything else is filling in the details of the goal state, discovering the circularities, and that we have the graph recorded in a redundant fashion in pkginfo.txt. The real data is the m3makefiles. longer answer: Randy, what is a "minimal" distribution? You have't defined the goal. What is "build"? You haven't defined the goal. I could just say: "Whatever you need, to build it, just download it from here." I'll define it as some arbitrary very minimal compiler and runtime set, specifically m3core and libm3. But you can have working Modula-3 programs certainly without libm3. And some Modula-3 programs will have a GUI so will want more libraries. What is "minimal"? And depending on future changes, the steps might change. Or maybe just pkginfo.txt will change. If there is no documentation and there is code, the code is the documentation. A lot of the code is declarative -- you look at the import statements in m3makefile. For given package foo, say "cm3", you walk the list of imports transitively. I'm not sure cm3 actually uses libm3 for example, and maybe it won't in the future. This is a very real point. pkginfo.txt duplicates dependency information by nature of being "in the correct order", but that information is already contained in the m3makefiles. Your questions have made me realize the redundancy we have and that we should fix it. Or, really, older cm3 did not use sysutils, but now it does. Things change. And you haven't really defined the goal. Instead of "walk pkginfo.txt in order", it should be "pick a package you want, say cm3, and build its dependency tree from the bottom up, using the m3makefiles to discover that tree, plus the PKGS file to locate packages". I'm going to make up a goal that might resemble yours and correct your instructions. > 1. Install Visual C++ 2008 Express Edition. ok. Though you don't need all of it by far. You don't need the entire IDE. > > 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. No. You don't need all of it. You only need two files -- cm3.exe and mklib.exe. Other platforms need cm3cg and don't need mklib. Except you never really need cm3cg, it falls out of the instructions -- cm3 can build it. It depends on how much you want to build vs. download. And optionally the config files. You can get them from either the source tree or download them. See, two legitimate places for things -- download from one place or another. > > > 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. No. You don't need all of it. You need, roughly, only m3-libs\m3core, m3-libs\libm3, m3-libs\sysutils, some of m3-sys. m3-sys/m3cc is needed for most platforms, but not the gcc-apple directory, that's only for iphone. > > 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" Not needed. > > 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" Not needed. > > 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. Many ways to do that. > > > 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. Multiple ways to do this but ok. > > > 8. mkdir "C:\cm3\bin\config" if it is missing ok. You can just mkdir unconditionally. > > > 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" You don't need all of it, but ok, that is what I do. > > > 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: > > INSTALL_ROOT = path() & "/.." > > include(path() & "/config/" & HOST) ok > > > 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) No. Well, it depends on the goal. Really. You already have a cm3. "min" gives you m3core and libm3. Combine that with the cm3 you already have and great, you have a slightly larger more useful set of libraries. > > > 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. NOt really. The repitition isn't doing what you say. Look at the group called "front". Which isn't completely accurate since it includes m3cc. Perhaps there should be a group compiler. But really, again, this is cm3 plus its transitive dependencies. I think maybe we need to partly ditch "groups". In paritcular, "groups" should contain useful end results and not their dependencies. m3middle doesn't belong in any group, it is just implied by cm3. Seriously. But the scripts don't currently read m3makefiles. Redoing things in cm3 would be better? > > > 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". Ok. Sort of. > > I know you've probably got scripts for all of this Yep. > Scripts are an expression of the requirements Sometimes it is the other way around. - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 31 06:28:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 00:28:55 -0400 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: Randy, I think this is a very useful exposition of the requirements for release distributions. I trust that your concerns can be addressed by Jay and Olaf. I must admit that, at this point, I have lost track of where things stand in the release installation process and hope soon to bring myself up to date. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 31 Jul 2009, at 00:14, Randy Coleburn wrote: > Jay: > > Thanks for your reply. I really appreciate your patience in dealing > with all my questions, especially during this busy time preparing > for the release. > > In response, I offer the following and also ask a few more questions: > > My use of the term "minimal" is consistent with what has been > documented in the working release documentation. Namely, that "min" > is the smallest distribution we plan to make available, versus "std" > that contains a "standard" distribution, versus "all" that contains > everything. > > Now as to the exact composition of "min" and "std" that is part of > my question. I assumed someone (you, Olaf, Tony, ?) has defined > what these mean. Further, if you look at PkgInfo.txt, it appears > that these definitions are recorded there, but again back to my > question as to whether these definitions are accurate, complete, > what the "cm3 community" wants/expects, and whether my understanding > of how they are used in the context of cm3 is indeed correct. > > I am well-versed in compilers and operating systems principles and > design, so I don't need a lecture on these fundamentals. My line of > questioning is concrete with respect to the impending cm3 release. > > My use of the term "build" is in the context of "cm3 -build", and to > be useful, subsequently "cm3 -ship". > > As a software/systems engineer, I understand what you mean when you > say that the code is the documentation when there is no external > documentation. However, I would hope you agree that no external > documentation is generally a bad thing. Hence my questions. I'm > not a python code writer yet, though I'm confident I could be, given > some time to learn. Thus, I can't presently rely on reading a > python script as documentation. I am confident that if you, Olaf, > Tony, or someone can confirm or correct my understanding of what > I've posed as the way to install the "min" distribution on Windows > and "build" the rest, that I can and will be able to document this > process externally for others to review. We can then check scripts > to see if they deviate from the documentation and make changes (to > either scripts or documentation) as needed to reflect reality. > > You state that I have not defined the "goal." Let me attempt to > make this obvious. I'm not trying to upset the apple cart here or > change the way you work to achieve progress/success. My goal simply > is to "understand" wrt the impending release so I can document, and > so I can "do the right thing" to make this work correctly on my > system. We can discuss in the future how things should change for > the next release. > > Thanks for help with my 13-steps. I have some comments and a few > more questions below. > > WRT #1, Yes, I know I may not need all of Visual Studio, but most > users will just choose the typical installation. If we have > specific minimums that need to be present, we should identify > (document) those for users who choose to customize their installation. > > WRT #2, you have to start somewhere. If we have both "min" and > "std" distributions, one can choose which to start with, but your > discussion of which parts to trim out of "min" should not be left to > the end user. The release team needs to establish what constitutes > "min". My "opinion" is that "min" should contain only what is > necessary for a working cm3 compiler, given the dependency on the > platform-specific linker. Using "min" one should be able to build > (cm3 -build -ship) all other packages. Anything added to "min" that > isn't necessary to accomplish building the remaining packages would > be considered superfluous, in my opinion. Some amount of > superfluous on a given platform may be tolerable in order to reach > consistency among all supported platforms regarding the composition > of "min". Thus, if cm3cg is needed for "min" on some platforms, but > not all, it is tolerable (IMO) to make it a standard component of > "min" on all platforms. > > WRT #3, point taken. However, unless we have an easy way to specify > and checkout only those parts of the tree relevant to a particular > platform, checking out everything ensures you haven't missed > something that is going to cause problems later. > > WRT#4, although doc may not be needed to run cm3, it is needed for > folks to reference and understand cm3. This is a long-standing > gripe of mine that we don't make the installation of doc part of the > typical installation. The naive user new to cm3 normally expects to > get some documentation. If the default is no documentation, how > does the poor sap know how to get the documentation and install it? > Also, cm3ide, does have links to the doc folder. If you click on > these links and they are broken, the average user is going to rate > cm3 as a poor product and move on to something else. Why create a > problem for the new user? Give him the documentation he needs by > default and let the expert user remove it if it is unwanted. I know > that Critical Mass's 4.1 installation put the doc folder there. > When did someone decide it wasn't appropriate for the default > installation? > > WRT#5, examples is needed for cm3ide. Right now, my bet is that > most everyone in the cm3 community doesn't know they should copy the > examples folder to the root of their cm3 installation. That's > because Reactor wasn't open-sourced until recently as cm3ide. Right > now the only documentation about this is a README file buried in the > repository and even that wouldn't be there if I hadn't put it > there. Again, don't create a problem for the new user. The > "typical" installation choice should install it by default. Let the > expert user choose to remove it as part of a custom install if it is > not wanted. > > WRT#6, agree. That's why I wasn't specific on how to do it, but for > the newbie, it would probably be best to list at least one way. > > WRT#7, agree. I was just stating my interpretation of what you had > communicated to me earlier about setting up config properly. > > WRT#8, ok, but you do get an error message if the folder exists > already. > > WRT#9, ditto #7 > > WRT#11, now we are finally getting to the meat of my questions. So, > if I understand you correctly, you are saying that building the > "min" group of packages does not recreate for me exactly what is > being published as the "min" distribution. In my view, we have a > conflict of terminology here that needs to be cleaned up. So what > exactly is "min" as defined in PkgInfo.txt if it doesn't represent > the minimal binary install? Furthermore, if I want to use cm3 to > build the sources for the compiler itself, it would seem from your > comments that "min" won't do it. Which packages need to built, and > in what order, to recreate cm3.exe ? > > Again you ask about the goal here, so let me be more explicit. > Given that cm3 continues to evolve and that minimal distributions > are created at unpredictable intervals, if one wants to ensure the > cm3 compiler is up-to-date with the latest sources, one would want > to start with some existing cm3 installation and build and ship the > compiler's source package(s) along with any other packages where a > dependency exists. In these instructions, I started with obtaining > the latest "min" distribution, then grabbed the current source tree, > so I want to proceed from this point to build a current cm3 compiler > and any other requisite components to again create a "minimal" > installation on my platform. From there, one can build some/all of > the remaining packages. > > WRT#12, the repeat is due to my prior understanding. Perhaps this > is incorrect, or perhaps the recent changes have made this > unnecessary. But, it seems my understanding of how to rebuild > cm3.exe is flawed given your response to #11. Are you saying I > should use "front" to build cm3.exe? Am I the only one to whom all > this is unclear? Again, we need to document for understanding. > > WRT#13, not sure what you mean by "sort of". What are the caveats? > > Regarding your comment at the end about scripts, I will respectfully > choose to disagree with you and hope that we work together to > improve documentation. After all, if we all get run over by a > truck, what we know in our brains isn't available to others unless > we've documented it somewhere. > > Thanks for your patience in putting up with all my questions! > Thanks also for all you are doing for cm3! > > Regards, > Randy Coleburn > >>>> Jay K 7/30/2009 4:11 PM >>> > > > Randy, the short answer is: > > Find a goal state in a graph, which you haven't clearly done, walk > that graph from the bottom up, and if there are circularities (there > are, you need to have cm3 first, before you can build cm3), you need > to download prebuilt files from somewhere (cm3 and mklib). > > > Everything else is filling in the details of the goal state, > discovering the circularities, and that we have the graph recorded > in a redundant fashion in pkginfo.txt. The real data is the > m3makefiles. > > > longer answer: > > > > Randy, what is a "minimal" distribution? You have't defined the goal. > What is "build"? You haven't defined the goal. > I could just say: "Whatever you need, to build it, just download it > from here." > > > I'll define it as some arbitrary very minimal compiler and runtime > set, specifically m3core and libm3. > But you can have working Modula-3 programs certainly without libm3. > And some Modula-3 programs will have a GUI so will want more > libraries. > What is "minimal"? > And depending on future changes, the steps might change. > Or maybe just pkginfo.txt will change. > If there is no documentation and there is code, the code is the > documentation. > > > A lot of the code is declarative -- you look at the import > statements in m3makefile. > For given package foo, say "cm3", you walk the list of imports > transitively -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 07:05:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 01:05:45 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content Message-ID: <4A7242E8.1E75.00D7.1@scires.com> Jay et al: On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. In particular, these are: BUILD_DIR PKG_USE DOC_INSTALL INSTALL_ROOT INITIAL_CM3_IDE_BROWSER INITIAL_CM3_IDE_EDITOR If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jul 31 08:10:35 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 08:10:35 +0200 Subject: [M3devel] M3Config In-Reply-To: References: <1248992439.2801.9.camel@faramir.m3w.org> Message-ID: <1249020635.2801.476.camel@faramir.m3w.org> Of course I do not insist. I need function, form is what someone with wider insight can decide much better. It's a bit... unusual... to depend on m3quake, but then... it's probably very unusual to read .M3WEB's too. I'll try it, thanks. dd On Fri, 2009-07-31 at 01:30 +0000, Jay K wrote: > It was partly unsupportable and you can trivially replace it with MxConfig. > Please try that -- MxConfig. MxConfig.Get() I recall. > > > We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). > > > - Jay > > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 31 Jul 2009 00:20:39 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] M3Config > > > > I have code reading data structure information from .M3WEB files.... And > > that code used M3Config for obvious things... Now when you killed it, > > how I am supposed (in portable way) to find these files? :) > > > > TIA, > > dd > > > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > >> So..I was wondering..what were the original authors thinking? > >> > >> And there was that comment about the file containing the data upon > >> install. > >> Which seemed wrong to me. > >> > >> They were probably thinking of the way 3.6 was packaged and > >> distributed -- everyone built the system from source, upon building > >> m3build/m3ship from C and m3 from assembly. > >> > >> That isn't a bad model, but we probably want both. > >> > >> There are at least three times the paths can be computed/recorded: > >> 1) when you build libm3 > >> 2) when you install libm3 > >> #1 and #2 may or may not be close in time and have the same result. > >> 3) by parsing cm3.cfg as needed > >> > >> #2 is more efficient than #3 and matches the old code, but #3 is how I > >> left it, probably ok. > >> > >> - Jay > >> > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 08:45:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 06:45:51 +0000 Subject: [M3devel] cl on windows In-Reply-To: <4A721600.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <4A721600.1E75.00D7.1@scires.com> Message-ID: > Again, I suspect your problem may be in using cygwin. I infer that you are using cygwin based on the path name below "C:\cygwin\usr\local...". Again, really, no. All both Cygwin and the vcvars32.bat are adding elements to %PATH%, and %LIB%, and %INCLUDE%, and adding files within the directories within %PATH%. The only way in which they collide is when they have file names in common, such as link.exe, or, indeed, python.exe. (or multiple copies of cygwin1.dll, because it uses a shared section, which is a security bug, which they seem to ignore that and just claim that Windows is insecure so they have no problem making things worse...multiple users who don't trust themselves have read/write access to some of each other's memory in this setup..) > if Jay succeeds in getting the python scripts to be truly "portable" > between the various platforms Again, I already have. I wrote them on a Mac to start, and since them have run on then OpenBSD, NetBSD, FreeBSD, Linux (Gentoo, Debian, maybe Red Hat), Solaris, NT, HP-UX, Cygwin, Interix, Darwin (not the full Mac OSX, which is where they ran first), and maybe more that is all I can remember. What are the errors you get? I have asked a few times. - Jay From jay.krell at cornell.edu Fri Jul 31 08:48:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 06:48:59 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content In-Reply-To: <4A7242E8.1E75.00D7.1@scires.com> References: <4A7242E8.1E75.00D7.1@scires.com> Message-ID: BUILD_DIR is defined. cm3 requires it too. It just isn't necessarily defined in the toplevel file, but in a file that gets included. > PKG_USE I believe that is also defined but I'll check. > DOC_INSTALL I doubt that is defined because I never saw it used. I can add it back. > INSTALL_ROOT That is certainly defined, and very important. > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR These are probably also not defined because I never saw them used. I can add them back..but they are actually very user specific. I can add defaults like: BROWSER=iexplore.exe EDITOR=notepad.exe BROWSER=firefox-bin EDITOR=/usr/bin/vi I'll do a little reserach and try to find defaults that work. - Jay ________________________________ > Date: Fri, 31 Jul 2009 01:05:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content > > > > > > > > Jay et al: > > > > On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. > > > > cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". > > > > I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. > > > > At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. > > > > In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. > > > > In particular, these are: > > BUILD_DIR > > PKG_USE > > DOC_INSTALL > > INSTALL_ROOT > > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR > > > > If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. > > > > I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. > > > > It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. > > > > Regards, > > Randy Coleburn From jay.krell at cornell.edu Fri Jul 31 09:06:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:06:15 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1248992267.2801.7.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: Please consider that you don't really need this CM3_INSTALL_PREFIX feature. I understand what it does. And the implementation is pretty small and ok. I don't mind leaving it in. And I think I fixed the problem with it. I hope it is clear that it isn't really needed. I will explain why. It isn't needed because the default ship location is adequate. The default ship location is the location of cm3, or one level up from there, or uh, whatever the config file says, but that is what it usually is. Now, granted, the location of cm3 "right now" might not be what you want. However, copying cm3 to where you want shipping to go is cheap, if in fact you are after building the whole system. If you are after just building a few packages, then, indeed, what I am saying makes less/no sense. gcc for example, is a bit heavyweight to copy around. It is many files. However cm3 is very small. If you want to ship somewhere else, you can do this: mkdir -p /tmp/foo/bin/config cd /tmp/foo/bin cp /usr/local/bin/cm3 . cp /usr/local/bin/cm3.cfg . cp /usr/local/bin/config/* config export PATH=/tmp/foo/bin:$PATH That's it. Then go about building the distribution, I'm not sure of the order here, but I'm sick of arguing about scripts and package groups and pkginfo.txt, the whole lot is unnecessary. cd $CVSROOT/m3-sys/m3cc cm3 -build cm3 -ship cd $CVSROOT/m3-libs/m3core cm3 -build cm3 -ship cd $CVSROOT/m3-libs/libm3 cm3 -build cm3 -ship cd $CVSROOT/m3-libs/sysutils cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3quake cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3middle cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3front cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3linker cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3back cm3 -build cm3 -ship cd $CVSROOT/m3-sys/cm3 cm3 -build cm3 -ship oops this line doesn't do anything useful # rem next line makes up for previous line not "working" cp build_dir/cm3 /tmp/foo/bin and continue on your way building/shipping whatever Again, if you just want to package up some gui apps for example, not the whole system from scratch, then CM3_INSTALL_PREFIX becomes more useful. I do wonder if the usage should have been cm3 -ship DESTDIR=/tmp/foo to follow widespread existing practice, but ok either way. Apple also uses a different name like DSTROOT for their linker/assembler and such. This technique is how I build distributions and I believe how Olaf does too, since I based my code on his. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Fri, 31 Jul 2009 00:17:47 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > cm3 -? > ... >> CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, >> "make DESTDIR=" behaviour for cm3 >> > > This is one patch I've introduced earlier and it's excellent conduit for > RPM packaging scripts I develop. I am using it like this: > > >> export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT >> >> ./scripts/do-pkg.sh realclean m3core libm3 >> >> ./scripts/do-pkg.sh buildship m3core libm3 >> > > Please let me know if your script fails on you mentioning mkdir failure. > I have workaround for it (as Jay did not accept my report as a bug). > > > I'll put my RPM script in repository RSN. > > dd > > On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: >> Hi Jay, >> >> Do you know of any way to tell the build system that the >> final installation directory is located in one place, but >> that the software is to actually be shipped (temporarily) >> to a staging directory. >> >> Specifically, libm3/src/config contains a m3makefile that >> derives the M3Config interface, containing a number of >> paths to the installation root directory. >> >> This is the normal situation for most people, but I am >> installing to a temporary directory, for packaging purposes. >> The packaging software later installs the package into >> the correct location. >> >> Whenever I build the system, M3Config always contains >> the paths to my staging area. >> >> I would like some way of specifying to the build system >> that the final (or real) installation root is one thing, >> but "ship" would actually install into a different one. >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 09:39:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:39:01 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: I'm sorry but I'm feeling very impatient... > Namely, that "min" is the smallest distribution we plan to make available Ok, that is clearer. That is not scientific but a matter of a decision. We could decide that min==std, not a bad decision really, since it gives users fewer confusing choices, and provides one package per platform, with no overlap. On the downside, it isn't small and some people might say we look fat. > My "opinion" is that "min" should contain only what is > necessary for a working cm3 compiler Now you have made a policy decision. An acceptable one. But not necessarily how it should and not necessarily consistent with some other things. > Anything added to "min" that isn't necessary to accomplish > building the remaining packages would be considered superfluous, > in my opinion. > Some amount of superfluous on a given platform may be > tolerable in order to reach consistency among all supported > platforms regarding the composition of "min". Thus, > if cm3cg is needed for "min" on some platforms, but not all, > it is tolerable (IMO) to make it a standard component of "min" > on all platforms. cm3cg doesn't really make sense on NT386 though. I've probably thrown it in somewhat by accident. If it is there, it'll depend on Cygwin, and NT386 will just ignore it completely, except for wasted diskspace, network traffic. > WRT#4, although doc may not be needed to run cm3, it is needed > for folks to reference and understand cm3. Now you are expanding the definition. The documentation is all online too. I'm certainly fine with including the documentation. Just be clear that "min"'s definition is expanding. (I'm fine with not distributing min at all, as I said, min==std?) > The naive user new to cm3 normally expects to get some documentation. I don't expect naive users to build cm3 themselves. This is in fact a reason not to provide min at all, but std. That way, the naive person who thinks he is expert won't make a mistake. Really. On the other hand, there are the masochists among us who use the Debian "netinst" and chose no additional packages during setup. :) If one has the time/patience, it can also be educational to create arbitrary difficult situations and work your way out of them. Really. (Why does anyone use Linux after all?) > If the default is no documentation, how does the poor sap know > how to get the documentation and install it? Poor saps should use "std", not "min". Right? What is "min"? The "minimum" distribution that is useful for "everyone" or the minimal distribution to build cm3? I should correct myself by the way. cm3cg is not needed in "min". It is "easily" just not quickly built from just cm3 and the m3-sys/m3cc part of the tree, and really cm3 is hardly needed for that (but cm3 is definitely needed for building everything else, so needed overall). > [Jay] docs/examples I think it was > The "typical" installation choice should install it by default. "typical" or "min"? > WRT#11, now we are finally getting to the meat of my questions. So, > if I understand you correctly, you are saying that building the "min" > group of packages does not recreate for me exactly what You must start with a prebuilt compiler (cm3). Whether you rebuild the compiler or not is somewhat a matter of taste. Indeed it is more tasteful to build it. In which case indeed, you need to build "front", but "front" need not be in the distribution. "front" is in fact basically just cm3, and I think cm3cg. Again again again, the "package groups" are just a redundant encoding of the dependency tree that is encoded in the m3makefiles. We could the entire scripts directory and pretty much everything would work about the same. It would just be a little tedious. More and more I think we should actually delete a lot of this. We should keep the PKGS file, or make cm3 able to figure it out, and the "scripts" should just accept an end goal -- "cm3", and it should read the m3makefiles and build the dependency graph from the buttom up to the goal. There could be special goal called "all", AND we could have the broken m3makefiles all filter themselves out. Perhaps a special group called "test", whose membership is implied by path? But now, you see, the more of these features I add, the more I'm back to reinventing these minor little scripts and package groups that we have. But do you see, that these aren't sort of all that significant? What you need to build is whatever m3makefiles lists in imports, and follow the transitive closure. And cm3cg is sort of different -- because it isn't a linked/library dependency, but rather because the config files tries to run a program (cm3cg) and that program needs to therefore exist somewhere. That is, the linked/library dependencies are encoded in a nice declarative way in the m3makefiles but the dependency on cm3cg is encoded in an imperative way. My interpretion of "min" has been roughly a minimal distribution that one can start with in order to build cm3, EVEN IF old cm3 cannot build m3core and libm3 from current source. The part I don't understand is that last point -- is it considered a recurring problem? Where is the line? What about sysutils? Is sysutils expected to be forever bound to be buildable by arbitrarily old compilers? Do we make a release shortly any such incompatibilities occur? Do we in fact not cater to such incompatibilities, and "min" therefore does NOT include m3core and libm3? Historically there was actually a more recurring problem here, around the list of targets. That is gone now. However there are still occasional problems like LONGINT. It seems to me this is somewhat of a problem of predicting the future, which is impossible. But also taking out very cheap insurance against the only fairly small number of bad futures. That is, throwing in m3core and libm3 is cheap, and it allows for future versions to not be compilable with old cm3, and that not being a big deal. This is all a bit gray and heuristic however. If today you start with a 5.4 or such cm3, indeed, you cannot build m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3. If you start with yesterday's cm3 however, you can build today's entire system, without also having yesterday's m3core/libm3 (nor cm3cg). See? It depends. And mitigating the worst case is perhaps worthwhile and cheap. And it depends because the system is necessarily circular. ("necessary" because the compiler is written in Modula-3) Breaking circular dependencies requires cheating. Changes in circular graphs can require cheating differently. If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay From dragisha at m3w.org Fri Jul 31 09:47:37 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 09:47:37 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: <1249026457.2801.578.camel@faramir.m3w.org> On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: > mkdir -p /tmp/foo/bin/config > cd /tmp/foo/bin > cp /usr/local/bin/cm3 . > cp /usr/local/bin/cm3.cfg . > cp /usr/local/bin/config/* config > export PATH=/tmp/foo/bin:$PATH Please tell me /usr/local/bin/config/* is mistake here... -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 09:54:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:54:19 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1249026457.2801.578.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> Message-ID: sorry /usr/local/cm3/bin -- or wherever cm3 is installed. I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. Just as /tmp/foo can be replaced by anything. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 09:47:37 +0200 > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: >> mkdir -p /tmp/foo/bin/config >> cd /tmp/foo/bin >> cp /usr/local/bin/cm3 . >> cp /usr/local/bin/cm3.cfg . >> cp /usr/local/bin/config/* config >> export PATH=/tmp/foo/bin:$PATH > > Please tell me /usr/local/bin/config/* is mistake here... > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 09:59:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:59:07 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: [truncated right about here..] If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changes. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay From jay.krell at cornell.edu Fri Jul 31 10:02:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 08:02:33 +0000 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: [wow severely truncated that time...trying again] [truncated right about here..] If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Fri, 31 Jul 2009 07:59:07 +0000 > Subject: Re: [M3devel] package groups question > > > [truncated right about here..] > > > If we do this, it is probably a good idea to also include sysutils in min From dragisha at m3w.org Fri Jul 31 10:00:11 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 10:00:11 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> Message-ID: <1249027211.2801.593.camel@faramir.m3w.org> My question was about location and names of secondary config files. Are these changed again? What would ne shipping procedure for compiler installation? Something new there? /cm3 is excellent idea, but on organized system (and if you package for general public) some standard location is preferred. I will change my locatio to /opt/cm3 now. dd On Fri, 2009-07-31 at 07:54 +0000, Jay K wrote: > sorry /usr/local/cm3/bin -- or wherever cm3 is installed. > I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. > > Just as /tmp/foo can be replaced by anything. > > - Jay > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 31 Jul 2009 09:47:37 +0200 > > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > > > On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: > >> mkdir -p /tmp/foo/bin/config > >> cd /tmp/foo/bin > >> cp /usr/local/bin/cm3 . > >> cp /usr/local/bin/cm3.cfg . > >> cp /usr/local/bin/config/* config > >> export PATH=/tmp/foo/bin:$PATH > > > > Please tell me /usr/local/bin/config/* is mistake here... > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 10:20:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 08:20:49 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1249027211.2801.593.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> <1249027211.2801.593.camel@faramir.m3w.org> Message-ID: The current layout is indeed: installroot/bin/cm3 installroot/bin/cm3.cfg installroot/bin/cm3cg installroot/bin/config/* There are imho too many files in config to put them in bin. cm3.cfg is just a two line stub: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) If you really want the files in, e.g. installroot/etc.: INSTALL_ROOT = path() & "/.." include(path() & "/../etc/" & HOST) or another example you could use is: cd $CVSROOT/m3-sys/cminstall/src/config-no-install cp *.common installroot/cm3/bin cp target installroot/cm3/bin/cm3.cfg or what I use: cd $CVSROOT/m3-sys/cminstall/src/config-no-install cp cm3.cfg installroot/cm3/bin That cm3.cfg delegates out to CM3_ROOT/m3-sys/cminstall/src/config-no-install so that when I am editing in CM3_ROOT/m3-sys/cminstall/src/config-no-install, I don't have to keep copying the file around and never accidentally edit the copy and then wipe it out by recopying it. It is an excellent model imho, but also not for everyone (ie. if you don't have the CVS tree!). It also provides for changing the TARGET somewhat on the fly on "multiarch" systems like NT386+Cygwin, SOLsun + SOLgnu, but I'm no longer liking that model and have started having /cm3, /cm3.cygwin, /cm3.interix on such systems instead. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 10:00:11 +0200 > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > My question was about location and names of secondary config files. Are > these changed again? What would ne shipping procedure for compiler > installation? Something new there? > > /cm3 is excellent idea, but on organized system (and if you package for > general public) some standard location is preferred. I will change my > locatio to /opt/cm3 now. > > dd > > On Fri, 2009-07-31 at 07:54 +0000, Jay K wrote: >> sorry /usr/local/cm3/bin -- or wherever cm3 is installed. >> I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. >> >> Just as /tmp/foo can be replaced by anything. >> >> - Jay >> >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> Date: Fri, 31 Jul 2009 09:47:37 +0200 >>> CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com >>> Subject: Re: [M3devel] M3Config contains paths to installation directory. >>> >>> On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: >>>> mkdir -p /tmp/foo/bin/config >>>> cd /tmp/foo/bin >>>> cp /usr/local/bin/cm3 . >>>> cp /usr/local/bin/cm3.cfg . >>>> cp /usr/local/bin/config/* config >>>> export PATH=/tmp/foo/bin:$PATH >>> >>> Please tell me /usr/local/bin/config/* is mistake here... >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From wagner at elegosoft.com Fri Jul 31 12:10:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 12:10:14 +0200 Subject: [M3devel] cl on windows In-Reply-To: <4A721600.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <4A721600.1E75.00D7.1@scires.com> Message-ID: <20090731121014.dhdyyt3af4s0gcoo@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > Using the "do-cm3.cmd" script that I checked in, I am currently able to > compile and link on both Windows XP and Vista all packages listed in > PkgInfo.txt , except for the packages that have been disabled via the > m3makefile for NT386. > > Again, I suspect your problem may be in using cygwin. I infer that you > are using cygwin based on the path name below "C:\cygwin\usr\local...". I don't think that the problems I encounter are related to cygwin. Think of it as just another shell to execute the production scripts. It's probably simply a broken Visual Studio installation. Tools like compiler and linker should work the same being called from bash or python or cmd.exe. > Again, this is further evidence why there needs to be a distinction > between a CM3 installation for Windows and one for cygwin running on > Windows; and why the supporting scripts may need to be different. Of > course, if Jay succeeds in getting the python scripts to be truly > "portable" between the various platforms, it may cut down on the > maintenance, since we won't need a different script for every platform. There should be a distinction concerning the target platforms (like NT386/NT386GNU as it used to be, but we'll rather use more adequate names). However, this is separate from the production and regression scripts we use. They may be written in shell or python or quake or whatever. I've always used the shell framework, so that's what I use to setup Hudson regression currently. > For now, I'm holding fast to Windows CMD because I can make it work and > I don't have to install anything else to get it to work. That's completely OK and a worthwhile task in itself. Unless you rewrite all the regression scripts in cmd, I cannot really use that though. Olaf > Regards, > Randy > >>>> Olaf Wagner 7/30/2009 1:23 PM >>> > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up > with. > > Compilation works now without a problem. I get as far as linking: > > new source -> compiling WinUserC.c > -> archiving m3core.lib > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 9 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > This seems to be a problem in the cm3 configuration files, right? > > More evidence: > > elego at wagner ~/work/cm3 > $ (cd m3-libs/m3core; cm3 -commands -build -keep) > --- building in NT386 --- > > cd NT386 > ignoring ..\src\m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale m3core.m3x > > -> archiving m3core.lib > rm m3core.lib > rm m3core.lib > rm m3core.lib.sa > rm m3core.dll > rm m3core.def > rm m3core.lst > rm m3core.dll.manifest > rm m3core.pdb > rm _m3responsefile0.txt > rm _m3responsefile1.txt > rm m3core.ilk > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > mklib @_m3responsefile0.txt 2>&1 > m3core.lst > rm m3core.lib > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > link @_m3responsefile1.txt 2>&1 > m3core.lst > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 6 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > cd .. > > elego at wagner ~/work/cm3 > $ cat m3-libs/m3core/NT386/_m3responsefile1.txt > -nodefaultlib > -debug > -incremental:no > -opt:ref > -delayload:wsock32.dll > -delayload:advapi32.dll > -delayload:gdi32.dll > -delayload:netapi32.dll > -delayload:user32.dll > -delayload:comctl32.dll > delayimp.lib > -def:m3core.def > -dll > -out:m3core.dll > -noentry > hand.obj > dtoa.obj > libgcc.obj > RTHooks.io > RTHooks.mo > [...lots of objects removed...] > kernel32.lib > msvcrt.lib > > > Olaf > > PS: I don't think that just returning 53 is the correct way to remind > users that some environment settings are missing though :-) > > Quoting Randy Coleburn : > >> Olaf: >> >> I don't think you want to be doing this with cygwin. That would > mean >> you are executing in a cygwin environment, not a true Windows-only >> environment. >> >> For the Visual Studio command line to work, you have to run the > script >> that sets up the environment variables. From the Windows Start > menu, >> there should be a menu tree labeled "Visual C++ 9.0 Express >> Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". >> Choosing this item from the menu will bring up a command prompt with > the >> environment set up properly. >> >> Alternately, you can run the following command from an existing > command >> prompt window: "C:\Program Files\Microsoft Visual Studio >> 9.0\VC\vcvarsall.bat x86" >> >> Note that the above command line assumes you have installed Visual > C++ >> 2008 Express Edition. The paths may be different for different > versions >> of the software. >> >> Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or >> cm3SetupCmdEnv.CMD), they do this all for you. >> >> Regards, >> Randy Coleburn > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Jul 31 14:31:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 08:31:15 -0400 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> Message-ID: <20090731123115.GA17620@topoi.pooq.com> On Thu, Jul 30, 2009 at 10:16:42PM +0200, Olaf Wagner wrote: > Quoting Peter Eiserloh : > > >Hi Olaf, > > > >www.eiserloh.org is my personal machine, on which I do most of my > >personal stuff. I have been putting things on its web > >server so other people can get to those public items I > >have made. > > > >I will probably have to get an account on birch or something. > > > >Speaking of debian packages, I am building a virtual machine > >for ARM_LINUX using qemu. Currently installing Debian Lenny > >in it. Inside which I will build set of CM3 debian packages > >for ARM. I wonder if that will make it easy to install CM3 programs on Nokia's internet tablets. -- hendrik From jay.krell at cornell.edu Fri Jul 31 14:36:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 12:36:26 +0000 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <20090731123115.GA17620@topoi.pooq.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> <20090731123115.GA17620@topoi.pooq.com> Message-ID: We should be a little careful with ARM_LINUX imho. And MIPS_LINUX. Those target name might be ok, and they'd refer to Linux 2.6+ with glibc. Many ARM and MIPS Linux systems aren't that. ARM has old ABI and new ABI, at the kernel level. It it also common to replace glibc with uclibc. I don't know if they are binary compatible or not. My Linux/arm machine/device is old ABI and uclibc. It seems that if you are building your own kernel, it is trivial to use old ABI. It isn't like it is incompatible with new hardware, I think. I think whoever put together the Western Digital MyBook World Edition just took the default. MIPS..well, I was surprised. I installed "Tomato" on my router. It is /very/ low end, but it does have a builtin SMB client, therefore it has infinite diskspace. It uses Linux 2.4, and I think/assume uclibc. MIPS also has big and little endian and I don't know if either is more common or if it is an even split. - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 08:31:15 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors > > On Thu, Jul 30, 2009 at 10:16:42PM +0200, Olaf Wagner wrote: >> Quoting Peter Eiserloh : >> >>>Hi Olaf, >>> >>>www.eiserloh.org is my personal machine, on which I do most of my >>>personal stuff. I have been putting things on its web >>>server so other people can get to those public items I >>>have made. >>> >>>I will probably have to get an account on birch or something. >>> >>>Speaking of debian packages, I am building a virtual machine >>>for ARM_LINUX using qemu. Currently installing Debian Lenny >>>in it. Inside which I will build set of CM3 debian packages >>>for ARM. > > I wonder if that will make it easy to install CM3 programs on Nokia's > internet tablets. > > -- hendrik From dragisha at m3w.org Fri Jul 31 14:43:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 14:43:41 +0200 Subject: [M3devel] M3Config In-Reply-To: <1249020635.2801.476.camel@faramir.m3w.org> References: <1248992439.2801.9.camel@faramir.m3w.org> <1249020635.2801.476.camel@faramir.m3w.org> Message-ID: <1249044221.27649.235.camel@faramir.m3w.org> Uhoh. I would like to use MxConfig.Get(), ok. It is in m3quake. Depending on m3middle. Depending on sysutils. Looks a bit too heavy for simple "where is ...?" processing. Can this logic be moved so I don't have to dynamicaly link large chunk of compiler code in every program using this functionality? TIA, dd On Fri, 2009-07-31 at 08:10 +0200, Dragi?a Duri? wrote: > Of course I do not insist. I need function, form is what someone with > wider insight can decide much better. It's a bit... unusual... to depend > on m3quake, but then... it's probably very unusual to read .M3WEB's too. > I'll try it, thanks. > > dd > > On Fri, 2009-07-31 at 01:30 +0000, Jay K wrote: > > It was partly unsupportable and you can trivially replace it with MxConfig. > > Please try that -- MxConfig. MxConfig.Get() I recall. > > > > > > We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > From: dragisha at m3w.org > > > To: jay.krell at cornell.edu > > > Date: Fri, 31 Jul 2009 00:20:39 +0200 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] M3Config > > > > > > I have code reading data structure information from .M3WEB files.... And > > > that code used M3Config for obvious things... Now when you killed it, > > > how I am supposed (in portable way) to find these files? :) > > > > > > TIA, > > > dd > > > > > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > > >> So..I was wondering..what were the original authors thinking? > > >> > > >> And there was that comment about the file containing the data upon > > >> install. > > >> Which seemed wrong to me. > > >> > > >> They were probably thinking of the way 3.6 was packaged and > > >> distributed -- everyone built the system from source, upon building > > >> m3build/m3ship from C and m3 from assembly. > > >> > > >> That isn't a bad model, but we probably want both. > > >> > > >> There are at least three times the paths can be computed/recorded: > > >> 1) when you build libm3 > > >> 2) when you install libm3 > > >> #1 and #2 may or may not be close in time and have the same result. > > >> 3) by parsing cm3.cfg as needed > > >> > > >> #2 is more efficient than #3 and matches the old code, but #3 is how I > > >> left it, probably ok. > > >> > > >> - Jay > > >> > > > -- > > > Dragi?a Duri? > > > -- Dragi?a Duri? From hendrik at topoi.pooq.com Fri Jul 31 15:13:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 09:13:41 -0400 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> <20090731123115.GA17620@topoi.pooq.com> Message-ID: <20090731131340.GC17620@topoi.pooq.com> On Fri, Jul 31, 2009 at 12:36:26PM +0000, Jay K wrote: > > We should be a little careful with ARM_LINUX imho. And MIPS_LINUX. > > > Those target name might be ok, and they'd refer to Linux 2.6+ with glibc. > Many ARM and MIPS Linux systems aren't that. > > > ARM has old ABI and new ABI, at the kernel level. Nokia uses the new ABI, I believe. Maemo, its OS, is debian-derived, but it is *not* Debian. Though it is possible to set it up to use Debian user-space in a chroot on the maemo kernel. > It it also common to replace glibc with uclibc. > I don't know if they are binary compatible or not. > My Linux/arm machine/device is old ABI and uclibc. So it's probably not. > It seems that if you are building your own kernel, > it is trivial to use old ABI. It isn't like it is incompatible > with new hardware, I think. I think whoever put together > the Western Digital MyBook World Edition just took the default. > > > MIPS..well, I was surprised. I installed "Tomato" on my router. > It is /very/ low end, but it does have a builtin SMB client, therefore > it has infinite diskspace. > It uses Linux 2.4, and I think/assume uclibc. > > > MIPS also has big and little endian and I don't know if either is > more common or if it is an even split. I know the hardware has that option -- it's controlled by a bit in some processor register. I remember wonderein, years ago, whether the OS allowed one to set that on a per-process basis, or even more finely. The situation reminds me of the IBM 360, which had a similar bit to control whether its native instructino set would support decimal operations in ASCII or in EBCDIC. But because changing that bit was a privileged operation, no one really got to set it, and everything was always EBCDIC. With the 370, I believe IBM discontinued the ASCII option. No one had ever used it. -- hendrik From hosking at cs.purdue.edu Fri Jul 31 15:42:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 09:42:19 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: I don't care if future versions are not compilable with old cm3. But, vice versa, old versions should always be compilable with new cm3. My gut feelings run along the lines of what Randy has said. I do think that the average user should accept std as the install, while min is for power-users who know what they are doing. Does that jive with other people's expectations? On 31 Jul 2009, at 03:39, Jay K wrote: > > I'm sorry but I'm feeling very impatient... > > > > >> Namely, that "min" is the smallest distribution we plan to make >> available > > > Ok, that is clearer. > That is not scientific but a matter of a decision. > We could decide that min==std, not a bad decision really, since it > gives users fewer confusing choices, and provides one package per > platform, with no overlap. > On the downside, it isn't small and some people might say we look fat. > > > > >> My "opinion" is that "min" should contain only what is >> necessary for a working cm3 compiler > > > Now you have made a policy decision. An acceptable one. > But not necessarily how it should and not necessarily consistent > with some other things. > > >> Anything added to "min" that isn't necessary to accomplish >> building the remaining packages would be considered superfluous, >> in my opinion. > >> Some amount of superfluous on a given platform may be >> tolerable in order to reach consistency among all supported >> platforms regarding the composition of "min". Thus, >> if cm3cg is needed for "min" on some platforms, but not all, >> it is tolerable (IMO) to make it a standard component of "min" >> on all platforms. > > > cm3cg doesn't really make sense on NT386 though. > I've probably thrown it in somewhat by accident. > If it is there, it'll depend on Cygwin, and NT386 will just ignore > it completely, except for wasted diskspace, network traffic. > > >> WRT#4, although doc may not be needed to run cm3, it is needed >> for folks to reference and understand cm3. > > > Now you are expanding the definition. The documentation is all > online too. > I'm certainly fine with including the documentation. Just be clear > that "min"'s definition is expanding. > (I'm fine with not distributing min at all, as I said, min==std?) > > >> The naive user new to cm3 normally expects to get some documentation. > > I don't expect naive users to build cm3 themselves. > This is in fact a reason not to provide min at all, but std. > That way, the naive person who thinks he is expert won't make a > mistake. > Really. On the other hand, there are the masochists among us who use > the Debian "netinst" and chose no additional packages during setup. :) > If one has the time/patience, it can also be educational to create > arbitrary difficult situations and work your way out of them. Really. > (Why does anyone use Linux after all?) > > >> If the default is no documentation, how does the poor sap know >> how to get the documentation and install it? > > > Poor saps should use "std", not "min". Right? > What is "min"? The "minimum" distribution that is useful for > "everyone" or the minimal distribution to build cm3? > > > I should correct myself by the way. > cm3cg is not needed in "min". > It is "easily" just not quickly built from just cm3 and the m3-sys/ > m3cc part of the tree, and really cm3 is hardly needed for that (but > cm3 is definitely needed for building everything else, so needed > overall). > > >> [Jay] docs/examples I think it was >> The "typical" installation choice should install it by default. > > > "typical" or "min"? > > >> WRT#11, now we are finally getting to the meat of my questions. So, >> if I understand you correctly, you are saying that building the "min" >> group of packages does not recreate for me exactly what > > > You must start with a prebuilt compiler (cm3). > Whether you rebuild the compiler or not is somewhat a matter of taste. > Indeed it is more tasteful to build it. > In which case indeed, you need to build "front", but "front" need > not be in the distribution. "front" is in fact basically just cm3, > and I think cm3cg. > > > Again again again, the "package groups" are just a redundant > encoding of the dependency tree that is encoded in the m3makefiles. > We could the entire scripts directory and pretty much everything > would work about the same. It would just be a little tedious. > > > More and more I think we should actually delete a lot of this. > We should keep the PKGS file, or make cm3 able to figure it out, and > the "scripts" should just accept an end goal -- "cm3", and it should > read the m3makefiles and build the dependency graph from the buttom > up to the goal. > > > There could be special goal called "all", AND we could have the > broken m3makefiles all filter themselves out. > > Perhaps a special group called "test", whose membership is implied > by path? > > > But now, you see, the more of these features I add, the more I'm > back to reinventing these minor little scripts and package groups > that we have. > > > But do you see, that these aren't sort of all that significant? > What you need to build is whatever m3makefiles lists in imports, and > follow the transitive closure. And cm3cg is sort of different -- > because it isn't a linked/library dependency, but rather because the > config files tries to run a program (cm3cg) and that program needs > to therefore exist somewhere. That is, the linked/library > dependencies are encoded in a nice declarative way in the > m3makefiles but the dependency on cm3cg is encoded in an imperative > way. > > > > > My interpretion of "min" has been roughly a minimal distribution > that one can start with in order to build cm3, EVEN IF old cm3 > cannot build m3core and libm3 from current source. The part I don't > understand is that last point -- is it considered a recurring > problem? Where is the line? What about sysutils? Is sysutils > expected to be forever bound to be buildable by arbitrarily old > compilers? > > > Do we make a release shortly any such incompatibilities occur? > Do we in fact not cater to such incompatibilities, and "min" > therefore does NOT include m3core and libm3? > > > Historically there was actually a more recurring problem here, > around the list of targets. That is gone now. However there are > still occasional problems like LONGINT. It seems to me this is > somewhat of a problem of predicting the future, which is impossible. > But also taking out very cheap insurance against the only fairly > small number of bad futures. That is, throwing in m3core and libm3 > is cheap, and it allows for future versions to not be compilable > with old cm3, and that not being a big deal. > This is all a bit gray and heuristic however. > > > If today you start with a 5.4 or such cm3, indeed, you cannot build > m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3. > > > If you start with yesterday's cm3 however, you can build today's > entire system, without also having yesterday's m3core/libm3 (nor > cm3cg). > > > See? It depends. > And mitigating the worst case is perhaps worthwhile and cheap. > > > And it depends because the system is necessarily circular. > ("necessary" because the compiler is written in Modula-3) > Breaking circular dependencies requires cheating. > Changes in circular graphs can require cheating differently. > > > > If we do this, it is probably a good idea to also include sysutils > in min -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 31 15:42:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 09:42:33 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <767A3979-1061-449C-8B28-900EE49D2848@cs.purdue.edu> Correct. On 31 Jul 2009, at 03:59, Jay K wrote: > > [truncated right about here..] > > > If we do this, it is probably a good idea to also include sysutils > in min -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 31 16:05:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 16:05:46 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> Quoting Tony Hosking : > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Sorry, I only now caught up with _some_ of the mails on the m3devel list. Too much traffic for me to digest. I gather there's been a long discussion that `min' is not really useful as it is not enough to build the system. When we started the cm3 5 business many years ago with lots of uncompilable sources from Farshad Nayeri, we invented the following sets of packages: all - obvious meaning. most packages did not compile at all. std - the set of packages shipped as compilable and usable with every new release core - a useful but small set of packages including everything to bootstrap the compiler boot - the minimal set to bootstrap the compiler min - the minimal set useful for anyone (not wanting to compiler cm3) As of today, std = all, and boot isn't used any more as far as a I see. I'm fine with any changes in the pragmatics or intended use of these package sets though. Just wanted to throw in some history. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Jul 31 17:13:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:13:58 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> Message-ID: <20090731151357.GA18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > >I don't care if future versions are not compilable with old cm3. But, > >vice versa, old versions should always be compilable with new cm3. > > > >My gut feelings run along the lines of what Randy has said. I do > >think that the average user should accept std as the install, while > >min is for power-users who know what they are doing. Does that jive > >with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. Is that becaouse no one ever boots the compiler any more? Or because there are better ways to do it? -- hendrik > > I'm fine with any changes in the pragmatics or intended use of these > package sets though. Just wanted to throw in some history. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Fri Jul 31 17:19:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:19:15 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <20090731151914.GB18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 09:42:19AM -0400, Tony Hosking wrote: > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Debian treats packages that share code as an anathema. So if there's a min package, they'd insist that std has the min parts removed from it, and depend on the min package instead of including it. Of course, the package description of the min package could gently advise potential users that they probably want to use the 'std' package instead... -- hendrik From hendrik at topoi.pooq.com Fri Jul 31 17:20:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:20:48 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731151357.GA18289@topoi.pooq.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> Message-ID: <20090731152047.GC18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > > >I don't care if future versions are not compilable with old cm3. But, > > >vice versa, old versions should always be compilable with new cm3. > > > > > >My gut feelings run along the lines of what Randy has said. I do > > >think that the average user should accept std as the install, while > > >min is for power-users who know what they are doing. Does that jive > > >with other people's expectations? > > > > Sorry, I only now caught up with _some_ of the mails on the m3devel > > list. Too much traffic for me to digest. > > > > I gather there's been a long discussion that `min' is not really > > useful as it is not enough to build the system. When we started > > the cm3 5 business many years ago with lots of uncompilable sources > > from Farshad Nayeri, we invented the following sets of packages: > > > > all - obvious meaning. most packages did not compile at all. > > std - the set of packages shipped as compilable and usable with > > every new release > > core - a useful but small set of packages including everything to > > bootstrap the compiler > > boot - the minimal set to bootstrap the compiler > > min - the minimal set useful for anyone (not wanting to compiler cm3) > > > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik I guess I should mention that ebian is perfectly happy if one source parckage (possibly the entire working cm3 system) generates multiple binary packages. -- hendrik From rcoleburn at scires.com Fri Jul 31 17:33:09 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 11:33:09 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content Message-ID: <4A72D418020000D70005DF1C@scires.com> Jay: The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. Regards, Randy Coleburn >>> Jay K 07/31/09 2:51 AM >>> BUILD_DIR is defined. cm3 requires it too. It just isn't necessarily defined in the toplevel file, but in a file that gets included. > PKG_USE I believe that is also defined but I'll check. > DOC_INSTALL I doubt that is defined because I never saw it used. I can add it back. > INSTALL_ROOT That is certainly defined, and very important. > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR These are probably also not defined because I never saw them used. I can add them back..but they are actually very user specific. I can add defaults like: BROWSER=iexplore.exe EDITOR=notepad.exe BROWSER=firefox-bin EDITOR=/usr/bin/vi I'll do a little reserach and try to find defaults that work. - Jay ________________________________ > Date: Fri, 31 Jul 2009 01:05:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content > > > > > > > > Jay et al: > > > > On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. > > > > cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". > > > > I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. > > > > At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. > > > > In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. > > > > In particular, these are: > > BUILD_DIR > > PKG_USE > > DOC_INSTALL > > INSTALL_ROOT > > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR > > > > If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. > > > > I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. > > > > It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. > > > > Regards, > > Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 17:27:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 15:27:57 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090731152047.GC18289@topoi.pooq.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> Message-ID: What does it mean to boot the compiler? I build the compiler from nothing but the compiler itself, and config files, and C compiler and linker, cvs to get all the source. That's not nothing, but it about the smallest start you can have, unless you rewrite the compiler in C, then you can start without the Modula-3 compiler. But at certain points in time this would not work, due to m3core and/or libm3 problems. It does work today. Is that booting? In future I'd like to dynamically link cm3, so I'd start with cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" dependencies. Many other systems do dynamically link to this extent and we can to. I'm not just being obnoxious. Really, what does it mean? Should we just ship std and that's it? And even drop the name from it? cm3-PPC_LINUX-5.8.2.tar.gz ? (No need to say "POSIX", it is redundant). Just one download per platform? Not a big matrix of packages to test? Or do we look too fat in that packaging? :) Will too much stuff confuse users? Or mitigate the bulk with a little documentation/tutorial? Something like this: There are many libraries and packages. You do not need to worry about them. Here is hello world for a command line program: ... And for a gui program: ... And a minimal sample interoperating with C: ... And a minimal sample using Modula-3's RPC called "network objects": ... CM3 4.1 had some like this that were nice, presumably we have them. - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>> Quoting Tony Hosking : >>> >>>>I don't care if future versions are not compilable with old cm3. But, >>>>vice versa, old versions should always be compilable with new cm3. >>>> >>>>My gut feelings run along the lines of what Randy has said. I do >>>>think that the average user should accept std as the install, while >>>>min is for power-users who know what they are doing. Does that jive >>>>with other people's expectations? >>> >>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>> list. Too much traffic for me to digest. >>> >>> I gather there's been a long discussion that `min' is not really >>> useful as it is not enough to build the system. When we started >>> the cm3 5 business many years ago with lots of uncompilable sources >>> from Farshad Nayeri, we invented the following sets of packages: >>> >>> all - obvious meaning. most packages did not compile at all. >>> std - the set of packages shipped as compilable and usable with >>> every new release >>> core - a useful but small set of packages including everything to >>> bootstrap the compiler >>> boot - the minimal set to bootstrap the compiler >>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>> >>> As of today, std = all, and boot isn't used any more as far as a I see. >> >> Is that becaouse no one ever boots the compiler any more? Or because >> there are better ways to do it? >> >> -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > From jay.krell at cornell.edu Fri Jul 31 17:31:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 15:31:14 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content In-Reply-To: <4A72D418020000D70005DF1C@scires.com> References: <4A72D418020000D70005DF1C@scires.com> Message-ID: MxConfig.Get() is able to retrieve the included part. MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. It is exactly the same code as the compiler uses. The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. Due to missing variables MxConfig would kind of give up and return NULL. I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. Maybe we should work this into the .msi?? - Jay ________________________________ > Date: Fri, 31 Jul 2009 11:33:09 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. > > > > I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. > > > > Regards, > > Randy Coleburn > >>>> Jay K 07/31/09 2:51 AM>>> > > BUILD_DIR is defined. > cm3 requires it too. > It just isn't necessarily defined in the toplevel file, but in a file that gets included. > >> PKG_USE > > > I believe that is also defined but I'll check. > > >> DOC_INSTALL > > I doubt that is defined because I never saw it used. I can add it back. > > >> INSTALL_ROOT > > > That is certainly defined, and very important. > > >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR > > > These are probably also not defined because I never saw them used. > I can add them back..but they are actually very user specific. > I can add defaults like: > > BROWSER=iexplore.exe > EDITOR=notepad.exe > > BROWSER=firefox-bin > EDITOR=/usr/bin/vi > > > I'll do a little reserach and try to find defaults that work. > > > - Jay > > ________________________________ >> Date: Fri, 31 Jul 2009 01:05:45 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >> >> >> >> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >> >> >> >> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >> >> >> >> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >> >> >> >> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >> >> >> >> In particular, these are: >> >> BUILD_DIR >> >> PKG_USE >> >> DOC_INSTALL >> >> INSTALL_ROOT >> >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR >> >> >> >> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >> >> >> >> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >> >> >> >> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >> >> >> >> Regards, >> >> Randy Coleburn From hendrik at topoi.pooq.com Fri Jul 31 17:51:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:51:05 -0400 Subject: [M3devel] Platform names Message-ID: <20090731155105.GA18363@topoi.pooq.com> Just to make life complicated, Debian has announced that the next release (squeeze, once it's stable) will have multiarch support (which means we'll be able to run 32-bit and 64-bit programs on AMD64), and that it will support both the Linux and BSD kernels. So Debian won't necessarily be a Linux system any more. -- hendrik From rcoleburn at scires.com Fri Jul 31 18:01:24 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 12:01:24 -0400 Subject: [M3devel] package groups question Message-ID: <4A72DD14020000D70005DF68@scires.com> Olaf: Thanks for the brief history lesson. These definitions coincide with my recollection. >From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". My problem has been a misunderstanding of "min", having thought that I could use min to bootstrap the compiler. My bad here. Jay has been talking about tracing graphs and figuring out everything from m3makefiles. In a distributed development environment, I'm not sure this approach works well. I am fine with continued use of PkgInfo.txt. I've been able to generate scripts using it with relative ease. For this release, I think we have at least 2 groups of "users" to be supported: 1. The power users who know enough to tweak the details of their installation, rebuild the compiler, etc. etc. They want the flexibility to tailor everything. You, Jay, Tony, etc. are in this camp. 2. The average or even new user who just wants a simple install that works out-of-the-box. He doesn't want anything complicated to install. He probably won't rebuild the compiler and is content to update his system whenever a new release is made. Obviously, folks from camp #2 may promote themselves to camp #1 after sufficient experience. If we agree on these two camps, I think that your definition of "min" is ok, but I would argue that "std" should include the documentation, examples, and pre-built binaries and sources for all packages known to work on all platforms. That would allow "std" to satisfy camp #2. Thus, "std" should be the recommended option for most users. The power users in camp #1 can start with either "min" or "std" and they have the knowledge to transform either of these into "all" or whatever sub-grouping they want. I appreciate everything Jay is doing, but I think he is so deep in the details right now, and also still looking forward past this release, that his responses to my questions aren't really answering what I'm trying to discuss regarding nailing down this release. Sure, with complete knowledge you can do most anything, but I'm looking at what I can do using cm3ide and the cm3.exe builder/compiler and the "min" and "std" releases using the default install locations. I'm heading south for a family reunion. I'll try to check email some this weekend, but it will be sparse. As soon as I can, I'll try to put some of what I've gleaned in a text file we can add to the documentation/web. Regards, Randy Coileburn >>> Olaf Wagner 07/31/09 10:08 AM >>> Quoting Tony Hosking : > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Sorry, I only now caught up with _some_ of the mails on the m3devel list. Too much traffic for me to digest. I gather there's been a long discussion that `min' is not really useful as it is not enough to build the system. When we started the cm3 5 business many years ago with lots of uncompilable sources from Farshad Nayeri, we invented the following sets of packages: all - obvious meaning. most packages did not compile at all. std - the set of packages shipped as compilable and usable with every new release core - a useful but small set of packages including everything to bootstrap the compiler boot - the minimal set to bootstrap the compiler min - the minimal set useful for anyone (not wanting to compiler cm3) As of today, std = all, and boot isn't used any more as far as a I see. I'm fine with any changes in the pragmatics or intended use of these package sets though. Just wanted to throw in some history. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 18:09:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 12:09:57 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content Message-ID: <4A72DF15020000D70005DF87@scires.com> Jay: The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly. I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.) Let me know if you have any ideas on why Vista is different in this regard. Regards, Randy >>> Jay K 07/31/09 11:33 AM >>> MxConfig.Get() is able to retrieve the included part. MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. It is exactly the same code as the compiler uses. The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. Due to missing variables MxConfig would kind of give up and return NULL. I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. Maybe we should work this into the .msi?? - Jay ________________________________ > Date: Fri, 31 Jul 2009 11:33:09 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. > > > > I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. > > > > Regards, > > Randy Coleburn > >>>> Jay K 07/31/09 2:51 AM>>> > > BUILD_DIR is defined. > cm3 requires it too. > It just isn't necessarily defined in the toplevel file, but in a file that gets included. > >> PKG_USE > > > I believe that is also defined but I'll check. > > >> DOC_INSTALL > > I doubt that is defined because I never saw it used. I can add it back. > > >> INSTALL_ROOT > > > That is certainly defined, and very important. > > >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR > > > These are probably also not defined because I never saw them used. > I can add them back..but they are actually very user specific. > I can add defaults like: > > BROWSER=iexplore.exe > EDITOR=notepad.exe > > BROWSER=firefox-bin > EDITOR=/usr/bin/vi > > > I'll do a little reserach and try to find defaults that work. > > > - Jay > > ________________________________ >> Date: Fri, 31 Jul 2009 01:05:45 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >> >> >> >> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >> >> >> >> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >> >> >> >> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >> >> >> >> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >> >> >> >> In particular, these are: >> >> BUILD_DIR >> >> PKG_USE >> >> DOC_INSTALL >> >> INSTALL_ROOT >> >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR >> >> >> >> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >> >> >> >> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >> >> >> >> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >> >> >> >> Regards, >> >> Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:21:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:21:22 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content In-Reply-To: <4A72DF15020000D70005DF87@scires.com> References: <4A72DF15020000D70005DF87@scires.com> Message-ID: Randy, when you test start /wait on Vista (or XP for that matter), make sure first that there are no instances of iexplore.exe in taskmgr. I bet what is happening is that the new iexplore.exe you ran actually did exit. Each user should probably have his own web server? Or, what is wrong with keeping the web server running even after the browser exits? I will double check BUILD_DIR, but the code is shared with cm3. How about the other variables? Vista vs. XP should not matter here. - Jay ________________________________ > Date: Fri, 31 Jul 2009 12:09:57 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly. > > > > I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.) > > > > Let me know if you have any ideas on why Vista is different in this regard. > > > > Regards, > > Randy > >>>> Jay K 07/31/09 11:33 AM>>> > > MxConfig.Get() is able to retrieve the included part. > MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. > It is exactly the same code as the compiler uses. > The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. > Due to missing variables MxConfig would kind of give up and return NULL. > > > I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. > > > Maybe we should work this into the .msi?? > > > - Jay > > > ________________________________ >> Date: Fri, 31 Jul 2009 11:33:09 -0400 >> From: rcoleburn at scires.com >> To: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content >> >> >> >> Jay: >> >> >> >> The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. >> >> >> >> I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay K 07/31/09 2:51 AM>>> >> >> BUILD_DIR is defined. >> cm3 requires it too. >> It just isn't necessarily defined in the toplevel file, but in a file that gets included. >> >>> PKG_USE >> >> >> I believe that is also defined but I'll check. >> >> >>> DOC_INSTALL >> >> I doubt that is defined because I never saw it used. I can add it back. >> >> >>> INSTALL_ROOT >> >> >> That is certainly defined, and very important. >> >> >>> INITIAL_CM3_IDE_BROWSER >>> >>> INITIAL_CM3_IDE_EDITOR >> >> >> These are probably also not defined because I never saw them used. >> I can add them back..but they are actually very user specific. >> I can add defaults like: >> >> BROWSER=iexplore.exe >> EDITOR=notepad.exe >> >> BROWSER=firefox-bin >> EDITOR=/usr/bin/vi >> >> >> I'll do a little reserach and try to find defaults that work. >> >> >> - Jay >> >> ________________________________ >>> Date: Fri, 31 Jul 2009 01:05:45 -0400 >>> From: rcoleburn at scires.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >>> >>> >>> >>> >>> >>> >>> >>> Jay et al: >>> >>> >>> >>> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >>> >>> >>> >>> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >>> >>> >>> >>> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >>> >>> >>> >>> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >>> >>> >>> >>> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >>> >>> >>> >>> In particular, these are: >>> >>> BUILD_DIR >>> >>> PKG_USE >>> >>> DOC_INSTALL >>> >>> INSTALL_ROOT >>> >>> INITIAL_CM3_IDE_BROWSER >>> >>> INITIAL_CM3_IDE_EDITOR >>> >>> >>> >>> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >>> >>> >>> >>> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >>> >>> >>> >>> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >>> >>> >>> >>> Regards, >>> >>> Randy Coleburn From wagner at elegosoft.com Fri Jul 31 18:27:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 18:27:47 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> Message-ID: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> I meant getting the first instance of cm3 5.1 run on a certain platform. And there was of course a first platform. We used the SRC compiler, the cm3 4.1 from Critical Mass, and the PM3 compiler on different platforms. Later we used cross-compilation almost exclusively. I assume that cross-compilation support has improved dramatically with all your changes. Olaf Quoting Jay K : > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- >> Date: Fri, 31 Jul 2009 11:20:48 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>> Quoting Tony Hosking : >>>> >>>>> I don't care if future versions are not compilable with old cm3. But, >>>>> vice versa, old versions should always be compilable with new cm3. >>>>> >>>>> My gut feelings run along the lines of what Randy has said. I do >>>>> think that the average user should accept std as the install, while >>>>> min is for power-users who know what they are doing. Does that jive >>>>> with other people's expectations? >>>> >>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>> list. Too much traffic for me to digest. >>>> >>>> I gather there's been a long discussion that `min' is not really >>>> useful as it is not enough to build the system. When we started >>>> the cm3 5 business many years ago with lots of uncompilable sources >>>> from Farshad Nayeri, we invented the following sets of packages: >>>> >>>> all - obvious meaning. most packages did not compile at all. >>>> std - the set of packages shipped as compilable and usable with >>>> every new release >>>> core - a useful but small set of packages including everything to >>>> bootstrap the compiler >>>> boot - the minimal set to bootstrap the compiler >>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>> >>>> As of today, std = all, and boot isn't used any more as far as a I see. >>> >>> Is that becaouse no one ever boots the compiler any more? Or because >>> there are better ways to do it? >>> >>> -- hendrik >> >> I guess I should mention that ebian is perfectly happy if one source >> parckage (possibly the entire working cm3 system) generates multiple >> binary packages. >> >> -- hendrik >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jul 31 18:31:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 12:31:49 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add? On 31 Jul 2009, at 12:27, Olaf Wagner wrote: > I meant getting the first instance of cm3 5.1 run on a certain > platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >> dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >>> wrote: >>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>> Quoting Tony Hosking : >>>>> >>>>>> I don't care if future versions are not compilable with old >>>>>> cm3. But, >>>>>> vice versa, old versions should always be compilable with new >>>>>> cm3. >>>>>> >>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>> think that the average user should accept std as the install, >>>>>> while >>>>>> min is for power-users who know what they are doing. Does that >>>>>> jive >>>>>> with other people's expectations? >>>>> >>>>> Sorry, I only now caught up with _some_ of the mails on the >>>>> m3devel >>>>> list. Too much traffic for me to digest. >>>>> >>>>> I gather there's been a long discussion that `min' is not really >>>>> useful as it is not enough to build the system. When we started >>>>> the cm3 5 business many years ago with lots of uncompilable >>>>> sources >>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>> >>>>> all - obvious meaning. most packages did not compile at all. >>>>> std - the set of packages shipped as compilable and usable with >>>>> every new release >>>>> core - a useful but small set of packages including everything to >>>>> bootstrap the compiler >>>>> boot - the minimal set to bootstrap the compiler >>>>> min - the minimal set useful for anyone (not wanting to compiler >>>>> cm3) >>>>> >>>>> As of today, std = all, and boot isn't used any more as far as a >>>>> I see. >>>> >>>> Is that becaouse no one ever boots the compiler any more? Or >>>> because >>>> there are better ways to do it? >>>> >>>> -- hendrik >>> >>> I guess I should mention that ebian is perfectly happy if one source >>> parckage (possibly the entire working cm3 system) generates multiple >>> binary packages. >>> >>> -- hendrik >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:35:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:35:19 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: I actually think cross compilation support might have been very good in the first place. :) In either case, yes, cross compilation support is good and easy now, if it wasn't earlier. I only ever cross compile cm3 itself though, not the entire system. Mainly what I did is some automation in pylib.py, which isn't all it should be, but again, enough for cm3. It's arguably not much more than your scripts. Oh, well, I also changed cm3.cfg to probe around for a reasonable cm3cg, so I could stop constantly overwriting the One /cm3/bin/cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. Really we should ship to /cm3/bin/host/target/cm3cg probably. Cross compiling the entire system will be useful for distribution purposes, but not in this release probably. It will enable us to claim to build a distribution for some target, without actually having the target available..which is a little bit dishonest, granted, you couldn't have run the tests. However it also allows cross building the entire system for slow targets, that you do have and will run the tests on, e.g. iphone, mips network router, my SGI machine, etc. If you booted from other distributions...these package groups refer to something in them?? - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 18:27:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>> Quoting Tony Hosking : >>>>> >>>>>> I don't care if future versions are not compilable with old cm3. But, >>>>>> vice versa, old versions should always be compilable with new cm3. >>>>>> >>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>> think that the average user should accept std as the install, while >>>>>> min is for power-users who know what they are doing. Does that jive >>>>>> with other people's expectations? >>>>> >>>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>>> list. Too much traffic for me to digest. >>>>> >>>>> I gather there's been a long discussion that `min' is not really >>>>> useful as it is not enough to build the system. When we started >>>>> the cm3 5 business many years ago with lots of uncompilable sources >>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>> >>>>> all - obvious meaning. most packages did not compile at all. >>>>> std - the set of packages shipped as compilable and usable with >>>>> every new release >>>>> core - a useful but small set of packages including everything to >>>>> bootstrap the compiler >>>>> boot - the minimal set to bootstrap the compiler >>>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>>> >>>>> As of today, std = all, and boot isn't used any more as far as a I see. >>>> >>>> Is that becaouse no one ever boots the compiler any more? Or because >>>> there are better ways to do it? >>>> >>>> -- hendrik >>> >>> I guess I should mention that ebian is perfectly happy if one source >>> parckage (possibly the entire working cm3 system) generates multiple >>> binary packages. >>> >>> -- hendrik >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 31 18:43:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:43:04 +0000 Subject: [M3devel] package groups question In-Reply-To: <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> Message-ID: That reminds me, darn it.. Yes I think the INTEGER/FLOAT things are ok now. I had hit problems in float and/or double bootstrapping where host and target differed in endian and fixed it. There were also 32bit/64bit problems there maybe, also now believed fixed. And gcc used to be partly to blame for problems here, but has been fixed. I even suggested they rev the documented caveats about building for Alpha and I think they did. I do bootstrap from host-generated .s files. I understand you could bootstrap from .mc files instead. Maybe even textual ones? That you use as a distribution format? Advantages/disadvantages? Minor one is that you'd have to build m3cc without the small aid of cm3..not a big deal, just configure -disable-bootstrap -disable-multilibs && make and ignore all my little tweaks in the m3makefile. If not textual, mc files are less readable..but assembly is unreadable to most people anyway.. There are bugs here though. - I left in the hack you didn't like in order to bootstrap from 32bit to 64bit, where TEXTs are limited to 4gig, rather than some much larger value on 64bit systems. The front end should be doing target math there not host math. - You can't bootstrap from 64bit to 32bit due to some similar small bug in the front end. Probably also a target math vs. host math thing. We already have the code to simulate target math, we just have to use it a little more. (This is what gcc now uses gmp/mpfr for presumably, like wrt constant propagation.) - Jay ________________________________ > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Fri, 31 Jul 2009 12:31:49 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add? > > On 31 Jul 2009, at 12:27, Olaf Wagner wrote: > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K>: > > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hosking at cs.purdue.edu Fri Jul 31 18:46:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 12:46:26 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: Agreed, cross-compilation only needed for cm3 itself. PM3 used to distribute the derived .s files for each platform and installation required building cm3 from those. That way there was no need to deliver an executable cm3. It was all source. On 31 Jul 2009, at 12:35, Jay K wrote: > > I actually think cross compilation support might have been very good > in the first place. :) > In either case, yes, cross compilation support is good and easy now, > if it wasn't earlier. > I only ever cross compile cm3 itself though, not the entire system. > Mainly what I did is some automation in pylib.py, which isn't all it > should be, but again, enough for cm3. > It's arguably not much more than your scripts. > > > Oh, well, I also changed cm3.cfg to probe around for a reasonable > cm3cg, so I could stop constantly overwriting the One /cm3/bin/ > cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. > Really we should ship to /cm3/bin/host/target/cm3cg probably. > > > Cross compiling the entire system will be useful for distribution > purposes, but not in this release probably. > It will enable us to claim to build a distribution for some target, > without actually having the target available..which is a little bit > dishonest, granted, you couldn't have run the tests. > > > However it also allows cross building the entire system for slow > targets, that you do have and will run the tests on, e.g. iphone, > mips network router, my SGI machine, etc. > > > If you booted from other distributions...these package groups refer > to something in them?? > > > - Jay > > ---------------------------------------- >> Date: Fri, 31 Jul 2009 18:27:47 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> I meant getting the first instance of cm3 5.1 run on a certain >> platform. >> And there was of course a first platform. We used the SRC compiler, >> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >> platforms. Later we used cross-compilation almost exclusively. >> >> I assume that cross-compilation support has improved dramatically >> with all your changes. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> What does it mean to boot the compiler? >>> >>> >>> I build the compiler from nothing but the compiler itself, >>> and config files, and C compiler and linker, cvs >>> to get all the source. >>> That's not nothing, but it about the smallest start you can have, >>> unless you rewrite the compiler in C, then you can start without >>> the Modula-3 compiler. But at certain points in time this >>> would not work, due to m3core and/or libm3 problems. >>> It does work today. >>> >>> >>> Is that booting? >>> >>> >>> In future I'd like to dynamically link cm3, so I'd start with >>> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >>> dynamic" >>> dependencies. Many other systems do dynamically link to this extent >>> and we can to. >>> >>> >>> I'm not just being obnoxious. >>> Really, what does it mean? >>> >>> >>> Should we just ship std and that's it? >>> And even drop the name from it? >>> cm3-PPC_LINUX-5.8.2.tar.gz ? >>> >>> >>> (No need to say "POSIX", it is redundant). >>> Just one download per platform? >>> Not a big matrix of packages to test? >>> >>> >>> Or do we look too fat in that packaging? :) >>> >>> >>> Will too much stuff confuse users? >>> >>> >>> Or mitigate the bulk with a little documentation/tutorial? >>> >>> >>> Something like this: >>> >>> There are many libraries and packages. >>> You do not need to worry about them. >>> Here is hello world for a command line program: >>> ... >>> And for a gui program: >>> ... >>> And a minimal sample interoperating with C: >>> ... >>> And a minimal sample using Modula-3's RPC called "network objects": >>> ... >>> >>> CM3 4.1 had some like this that were nice, presumably we have them. >>> >>> - Jay >>> >>> >>> >>> >>> ---------------------------------------- >>>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>>> From: hendrik at topoi.pooq.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] package groups question >>>> >>>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >>>> wrote: >>>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> I don't care if future versions are not compilable with old >>>>>>> cm3. But, >>>>>>> vice versa, old versions should always be compilable with new >>>>>>> cm3. >>>>>>> >>>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>>> think that the average user should accept std as the install, >>>>>>> while >>>>>>> min is for power-users who know what they are doing. Does that >>>>>>> jive >>>>>>> with other people's expectations? >>>>>> >>>>>> Sorry, I only now caught up with _some_ of the mails on the >>>>>> m3devel >>>>>> list. Too much traffic for me to digest. >>>>>> >>>>>> I gather there's been a long discussion that `min' is not really >>>>>> useful as it is not enough to build the system. When we started >>>>>> the cm3 5 business many years ago with lots of uncompilable >>>>>> sources >>>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>>> >>>>>> all - obvious meaning. most packages did not compile at all. >>>>>> std - the set of packages shipped as compilable and usable with >>>>>> every new release >>>>>> core - a useful but small set of packages including everything to >>>>>> bootstrap the compiler >>>>>> boot - the minimal set to bootstrap the compiler >>>>>> min - the minimal set useful for anyone (not wanting to >>>>>> compiler cm3) >>>>>> >>>>>> As of today, std = all, and boot isn't used any more as far as >>>>>> a I see. >>>>> >>>>> Is that becaouse no one ever boots the compiler any more? Or >>>>> because >>>>> there are better ways to do it? >>>>> >>>>> -- hendrik >>>> >>>> I guess I should mention that ebian is perfectly happy if one >>>> source >>>> parckage (possibly the entire working cm3 system) generates >>>> multiple >>>> binary packages. >>>> >>>> -- hendrik >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:49:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:49:41 +0000 Subject: [M3devel] "how to build a distribution" Message-ID: On this matter there's actually more stuff worth mentioning. Like, you always need various packages/libraries/tools that are often not in default minimal OS installs. ODBC, X Windows, Postgres, bc, flex, bison, gcc, make, cvs, opengl, etc. None of those are in the default Debian netinst for example. And esp. the first few are not in many systems' default installations. You don't need any of these, except for gcc basically, to use Modula-3. But if you want to include all of "std", you need the C headers and/or librarie (often just libraries). I never was able to find opengl for I386_DARWIN (not MacOSX). - Jay From jay.krell at cornell.edu Fri Jul 31 18:53:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:53:05 +0000 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: I like that PM3/SRC model, just haven't (re)implemented it yet. In that model I believe we'd have binary and source distributions. binary for the less patient. Source for the less trusting. Albeit assembly source. something like that. The source distribution is also more portable, like to multiple versions of the OS, since the library names haven't been locked in yet -- Olaf and I found that OpenBSD is kind of a pain there, they rev the name of libc.so and apparently break old binaries. Maybe there is a compat option we didn't see (didn't look). We'll see about changes/progress here in future releases. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 12:46:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > Agreed, cross-compilation only needed for cm3 itself. PM3 used to distribute the derived .s files for each platform and installation required building cm3 from those. That way there was no need to deliver an executable cm3. It was all source. > > On 31 Jul 2009, at 12:35, Jay K wrote: > > > I actually think cross compilation support might have been very good in the first place. :) > In either case, yes, cross compilation support is good and easy now, if it wasn't earlier. > I only ever cross compile cm3 itself though, not the entire system. > Mainly what I did is some automation in pylib.py, which isn't all it should be, but again, enough for cm3. > It's arguably not much more than your scripts. > > > Oh, well, I also changed cm3.cfg to probe around for a reasonable cm3cg, so I could stop constantly overwriting the One /cm3/bin/cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. > Really we should ship to /cm3/bin/host/target/cm3cg probably. > > > Cross compiling the entire system will be useful for distribution purposes, but not in this release probably. > It will enable us to claim to build a distribution for some target, without actually having the target available..which is a little bit dishonest, granted, you couldn't have run the tests. > > > However it also allows cross building the entire system for slow targets, that you do have and will run the tests on, e.g. iphone, mips network router, my SGI machine, etc. > > > If you booted from other distributions...these package groups refer to something in them?? > > > - Jay > > ---------------------------------------- > Date: Fri, 31 Jul 2009 18:27:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hendrik at topoi.pooq.com Fri Jul 31 19:40:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 13:40:49 -0400 Subject: [M3devel] "how to build a distribution" In-Reply-To: References: Message-ID: <20090731174049.GA18464@topoi.pooq.com> On Fri, Jul 31, 2009 at 04:49:41PM +0000, Jay K wrote: > > On this matter there's actually more stuff worth mentioning. > > > Like, you always need various packages/libraries/tools that are often not in default minimal OS installs. > > > ODBC, X Windows, Postgres, bc, flex, bison, gcc, make, cvs, opengl, etc. > > > None of those are in the default Debian netinst for example. > And esp. the first few are not in many systems' default installations. >From the Debian binary point of view, the packages providing these should should be dependencies of the various libraries we generate that use them. Installing our library would then cause the other tools to be installed automatically. > > You don't need any of these, except for gcc basically, to use Modula-3. > But if you want to include all of "std", you need the C headers and/or librarie (often just libraries). Actually, Debian distinguishes several kind of packages: source packages -- the actual source code that people edit. binary packages -- what you need to use the software Usually executables and/or shared libraries doc -- often recommended or suggested by the binary packages and dev packages dev packages -- what you need to develop other software that uses the binary package. For C, this often consists of header files and kind of shim libraries that serve no purpose except to load the shared libraries. In our case, the source package for cm3 will probably have a build-dependency on one of the binary packages it generates. I wonder how C handles this. And how does this map onto the files Modula 3 uses and builds? -- hendrik From wagner at elegosoft.com Fri Jul 31 23:29:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 23:29:29 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: <20090731232929.r2v9z92sggkoogsc@mail.elegosoft.com> Quoting Tony Hosking : > Agreed, cross-compilation only needed for cm3 itself. PM3 used to > distribute the derived .s files for each platform and installation > required building cm3 from those. That way there was no need to > deliver an executable cm3. It was all source. I would like that to be possible with cm3, too. But we never built up the infrastructure to do it. Not for this release though ;-) Let's try to ge something delivered. Olaf > On 31 Jul 2009, at 12:35, Jay K wrote: > >> >> I actually think cross compilation support might have been very >> good in the first place. :) >> In either case, yes, cross compilation support is good and easy >> now, if it wasn't earlier. >> I only ever cross compile cm3 itself though, not the entire system. >> Mainly what I did is some automation in pylib.py, which isn't all >> it should be, but again, enough for cm3. >> It's arguably not much more than your scripts. >> >> >> Oh, well, I also changed cm3.cfg to probe around for a reasonable >> cm3cg, so I could stop constantly overwriting the One /cm3/bin/ >> cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. >> Really we should ship to /cm3/bin/host/target/cm3cg probably. >> >> >> Cross compiling the entire system will be useful for distribution >> purposes, but not in this release probably. >> It will enable us to claim to build a distribution for some target, >> without actually having the target available..which is a little >> bit dishonest, granted, you couldn't have run the tests. >> >> >> However it also allows cross building the entire system for slow >> targets, that you do have and will run the tests on, e.g. iphone, >> mips network router, my SGI machine, etc. >> >> >> If you booted from other distributions...these package groups refer >> to something in them?? >> >> >> - Jay >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 18:27:47 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> I meant getting the first instance of cm3 5.1 run on a certain platform. >>> And there was of course a first platform. We used the SRC compiler, >>> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >>> platforms. Later we used cross-compilation almost exclusively. >>> >>> I assume that cross-compilation support has improved dramatically >>> with all your changes. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> What does it mean to boot the compiler? >>>> >>>> >>>> I build the compiler from nothing but the compiler itself, >>>> and config files, and C compiler and linker, cvs >>>> to get all the source. >>>> That's not nothing, but it about the smallest start you can have, >>>> unless you rewrite the compiler in C, then you can start without >>>> the Modula-3 compiler. But at certain points in time this >>>> would not work, due to m3core and/or libm3 problems. >>>> It does work today. >>>> >>>> >>>> Is that booting? >>>> >>>> >>>> In future I'd like to dynamically link cm3, so I'd start with >>>> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" >>>> dependencies. Many other systems do dynamically link to this extent >>>> and we can to. >>>> >>>> >>>> I'm not just being obnoxious. >>>> Really, what does it mean? >>>> >>>> >>>> Should we just ship std and that's it? >>>> And even drop the name from it? >>>> cm3-PPC_LINUX-5.8.2.tar.gz ? >>>> >>>> >>>> (No need to say "POSIX", it is redundant). >>>> Just one download per platform? >>>> Not a big matrix of packages to test? >>>> >>>> >>>> Or do we look too fat in that packaging? :) >>>> >>>> >>>> Will too much stuff confuse users? >>>> >>>> >>>> Or mitigate the bulk with a little documentation/tutorial? >>>> >>>> >>>> Something like this: >>>> >>>> There are many libraries and packages. >>>> You do not need to worry about them. >>>> Here is hello world for a command line program: >>>> ... >>>> And for a gui program: >>>> ... >>>> And a minimal sample interoperating with C: >>>> ... >>>> And a minimal sample using Modula-3's RPC called "network objects": >>>> ... >>>> >>>> CM3 4.1 had some like this that were nice, presumably we have them. >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>>>> From: hendrik at topoi.pooq.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] package groups question >>>>> >>>>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>>>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> I don't care if future versions are not compilable with old cm3. But, >>>>>>>> vice versa, old versions should always be compilable with new cm3. >>>>>>>> >>>>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>>>> think that the average user should accept std as the install, while >>>>>>>> min is for power-users who know what they are doing. Does that jive >>>>>>>> with other people's expectations? >>>>>>> >>>>>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>>>>> list. Too much traffic for me to digest. >>>>>>> >>>>>>> I gather there's been a long discussion that `min' is not really >>>>>>> useful as it is not enough to build the system. When we started >>>>>>> the cm3 5 business many years ago with lots of uncompilable sources >>>>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>>>> >>>>>>> all - obvious meaning. most packages did not compile at all. >>>>>>> std - the set of packages shipped as compilable and usable with >>>>>>> every new release >>>>>>> core - a useful but small set of packages including everything to >>>>>>> bootstrap the compiler >>>>>>> boot - the minimal set to bootstrap the compiler >>>>>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>>>>> >>>>>>> As of today, std = all, and boot isn't used any more as far as >>>>>>> a I see. >>>>>> >>>>>> Is that becaouse no one ever boots the compiler any more? Or because >>>>>> there are better ways to do it? >>>>>> >>>>>> -- hendrik >>>>> >>>>> I guess I should mention that ebian is perfectly happy if one source >>>>> parckage (possibly the entire working cm3 system) generates multiple >>>>> binary packages. >>>>> >>>>> -- hendrik >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Wed Jul 1 11:03:19 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 01 Jul 2009 11:03:19 +0200 Subject: [M3devel] elego Servermaintenance 3.07.09 Message-ID: <20090701110319.l4ksn5e680ggg4kk@mail.elego.de> Liebe Kollegen, Liebe Elego-Kunden, In der Nacht von Freitag, dem 3.07 auf Samstag, den 4.07 werden wir um 22.00 CEST Uhr planmaessige Wartungsarbeiten an unseren Servern durchfuehren. Es kann zur kurzeitigen Unterbrechung mancher Dienste kommen. Voraussichtliche Dauer der Wartung: 120 Min. Wir bitten um Verst?ndnis. - die elego Admins On Friday, July 3 at 10 PM CEST, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 1 13:57:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Jul 2009 13:57:15 +0200 Subject: [M3devel] release build broken In-Reply-To: References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> Message-ID: <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> Quoting Jay : > > Ah, only the release build but not the latest, makes sense. > These weren't in m3core in older version. > Will fix. > After this release I can put it back. Jay, all the release builds are still broken in Tinderbox. Can you fix it your revert the offending commit? You also didn't answer if you're going to fix the path canonicalization function in quake. Can you do something there? Thanks, Olaf > > - Jay > > > > ---------------------------------------- >> Date: Tue, 30 Jun 2009 09:28:26 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release build broken >> >> The last commit to pkginfo.txt broke the Tinderbox release build: >> >> End of Log File >> "../src/Main.m3", line 4: unable to find interface (WinNT) >> "../src/Main.m3", line 5: unable to find interface (WinDef) >> compilation failed => not building program "mklib" >> Fatal Error: package build failed >> *** execution of cm3 -build >> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >> -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS >> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >> -DCM3_LAST_CHANGED=?2009-05-16? failed *** >> >> >> Please fix. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 1 17:45:05 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 15:45:05 +0000 Subject: [M3devel] release build broken In-Reply-To: <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> Message-ID: Release build should be ok now, for the next build. I'm not sure about the path stuff. What I was doing uses working code. - Jay ---------------------------------------- > Date: Wed, 1 Jul 2009 13:57:15 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release build broken > > Quoting Jay : > >> >> Ah, only the release build but not the latest, makes sense. >> These weren't in m3core in older version. >> Will fix. >> After this release I can put it back. > > Jay, > > all the release builds are still broken in Tinderbox. Can you fix it > your revert the offending commit? > > You also didn't answer if you're going to fix the path canonicalization > function in quake. Can you do something there? > > Thanks, > > Olaf > >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 30 Jun 2009 09:28:26 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] release build broken >>> >>> The last commit to pkginfo.txt broke the Tinderbox release build: >>> >>> End of Log File >>> "../src/Main.m3", line 4: unable to find interface (WinNT) >>> "../src/Main.m3", line 5: unable to find interface (WinDef) >>> compilation failed => not building program "mklib" >>> Fatal Error: package build failed >>> *** execution of cm3 -build >>> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >>> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >>> -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS >>> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >>> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >>> -DCM3_LAST_CHANGED=?2009-05-16? failed *** >>> >>> >>> Please fix. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 1 18:09:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 16:09:53 +0000 Subject: [M3devel] small builder bug when delete/rename files Message-ID: I believe there is a small builder bug for incremental builds when you move files: == package /home/jay/dev2/cm3/m3-sys/cm3 == +++ /tmp/tmpLXKqFE/compiler_with_previous/bin/cm3 -build -DROOT=/home/jay/dev2 /cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=20 09-05-16 @M3novm +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides Fatal Error: duplicate link info: M3Path.i3 *** execution of [, From jay.krell at cornell.edu Wed Jul 1 18:14:46 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 16:14:46 +0000 Subject: [M3devel] ChangeLog missing entries Message-ID: Many entries aren't interesting anyway, but the ChangeLog does miss stuff, at lease this one: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/intl/Attic/Makefile.in remove intl, libgomp, libssp, libmudflap that we don't build, use, or change http://modula3.elegosoft.com/cm3/ChangeLog-2009 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 1 18:54:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Jul 2009 18:54:03 +0200 Subject: [M3devel] ChangeLog missing entries In-Reply-To: References: Message-ID: <20090701185403.lgnqptijkg8g0w4w@mail.elegosoft.com> Quoting Jay : > Many entries aren't interesting anyway, but the ChangeLog does miss > stuff, at lease this one: > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/intl/Attic/Makefile.in > > remove intl, libgomp, libssp, libmudflap that we don't build, use, or > change > > > http://modula3.elegosoft.com/cm3/ChangeLog-2009 It's converted by a standard Perl script from the repository, IIRC. It's run by m3's crontab every on birch. Anybody there who'd like to have a look? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Jul 2 08:54:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Jul 2009 23:54:42 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Hi Modula-3ers (Tony?), I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot archive is broken on the web site... I remember there is some more or less hidden area where there are more archives, but I don't remember where? Mika From jay.krell at cornell.edu Thu Jul 2 09:08:58 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 07:08:58 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020654.n626sg3G082786@camembert.async.caltech.edu> References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: modula3.elegosoft.com/cm3/uploaded-archives But there aren't any I386_DARWIN. My I386_DARWIN seems to have a problem with its power supply, that's partly why nothing in releng. Can I suggest you try cross bootstrap? You know, so I can induct other people into my fun group? Here is how. Have some working machine already. Pretty much any platform. cd m3-sys/m3cc cm3 -DM3CC_TARGET=I386_DARWIN # That takes a little while. cd scripts/python cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. That config file delegates to the config files in the CVS tree. ./boot1.py I386_DARWIN This will produce something like ./cm3-boot-I386_DARWIN-1.tar.gz scp that file to your I386_DARWIN machine, then the rest is on the I386_DARWIN machine, extract it, cd into it, run make. That should give you cm3. Run it, make sure it runs ok, it should error about unable to find cm3.cfg. cvs checkout the whole tree. mkdir -p /usr/local/cm3/bin/config cp cm3 /usr/local/cm3/bin cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. You know have a working native bootstrap -- just cm3, cm3.cfg, the source tree. Complete the system with: ./do-cm3-std.py buildship - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Wed, 1 Jul 2009 23:54:42 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting I386_DARWIN? > > Hi Modula-3ers (Tony?), > > I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot > archive is broken on the web site... I remember there is some more or > less hidden area where there are more archives, but I don't remember > where? > > Mika From jay.krell at cornell.edu Thu Jul 2 09:41:56 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 07:41:56 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: Sorry, that was wrong: cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config should be: cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin I moved all the other files to config, but not cm3.cfg itself. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 07:08:58 +0000 > CC: mika at camembert.async.caltech.edu > Subject: Re: [M3devel] help booting I386_DARWIN? > > > modula3.elegosoft.com/cm3/uploaded-archives > > > But there aren't any I386_DARWIN. > My I386_DARWIN seems to have a problem with its power supply, that's partly why nothing in releng. > > > Can I suggest you try cross bootstrap? > You know, so I can induct other people into my fun group? > > > Here is how. > Have some working machine already. > Pretty much any platform. > > > cd m3-sys/m3cc > cm3 -DM3CC_TARGET=I386_DARWIN > # That takes a little while. > > > cd scripts/python > cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. > That config file delegates to the config files in the CVS tree. > > ./boot1.py I386_DARWIN > This will produce something like > ./cm3-boot-I386_DARWIN-1.tar.gz > > > scp that file to your I386_DARWIN machine, > then the rest is on the I386_DARWIN machine, > extract it, cd into it, run make. > That should give you cm3. > Run it, make sure it runs ok, it should error about unable to find cm3.cfg. > > > cvs checkout the whole tree. > mkdir -p /usr/local/cm3/bin/config > cp cm3 /usr/local/cm3/bin > cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. > > You know have a working native bootstrap -- just cm3, cm3.cfg, the source tree. > Complete the system with: > > > ./do-cm3-std.py buildship > > > > - Jay > > ---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Wed, 1 Jul 2009 23:54:42 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] help booting I386_DARWIN? >> >> Hi Modula-3ers (Tony?), >> >> I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot >> archive is broken on the web site... I remember there is some more or >> less hidden area where there are more archives, but I don't remember >> where? >> >> Mika From mika at async.caltech.edu Thu Jul 2 10:06:51 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 02 Jul 2009 01:06:51 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020806.n6286pFG085097@camembert.async.caltech.edu> Jay that's pretty nifty. The "cross" part of the build went fine (I figured out your config thing too), but it dies on the target: as PolyBasis.ms -o PolyBasis.ms.o as Main.is -o Main.is.o as WeakRef.ms -o WeakRef.ms.o as Word.ms -o Word.ms.o as Long.ms -o Long.ms.o gcc -g -fPIC -c hand.c -o hand.c.o gcc -g -fPIC -c dtoa.c -o dtoa.c.o gcc -g -fPIC -c libgcc.c -o libgcc.c.o gcc -g -fPIC -c RTLinkerC.c -o RTLinkerC.c.o gcc -g -fPIC -c RTOSmmap.c -o RTOSmmap.c.o gcc -g -fPIC -c RTSignalC.c -o RTSignalC.c.o RTSignalC.c: In function 'GetPC': RTSignalC.c:91: error: 'struct mcontext' has no member named 'sc' make: *** [RTSignalC.c.o] Error 1 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% uname -a Darwin unknown-00-17-f2-4c-66-5c.home 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% Am I perhaps using a hopeless version of OS X? Mika From jay.krell at cornell.edu Thu Jul 2 10:46:26 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 08:46:26 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020806.n6286pFG085097@camembert.async.caltech.edu> References: <200907020806.n6286pFG085097@camembert.async.caltech.edu> Message-ID: Just change the function GetPC to return 0 and move on, for now. We'll fix it correctly "later". I assume you are running 10.5? It worked for me on 10.4. There might be an #ifdef we can use to make it work on both. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jayk123 at hotmail.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 01:06:51 -0700 > From: mika at async.caltech.edu > > Jay that's pretty nifty. The "cross" part of the build went fine (I > figured out your config thing too), but it dies on the target: > > as PolyBasis.ms -o PolyBasis.ms.o > as Main.is -o Main.is.o > as WeakRef.ms -o WeakRef.ms.o > as Word.ms -o Word.ms.o > as Long.ms -o Long.ms.o > gcc -g -fPIC -c hand.c -o hand.c.o > gcc -g -fPIC -c dtoa.c -o dtoa.c.o > gcc -g -fPIC -c libgcc.c -o libgcc.c.o > gcc -g -fPIC -c RTLinkerC.c -o RTLinkerC.c.o > gcc -g -fPIC -c RTOSmmap.c -o RTOSmmap.c.o > gcc -g -fPIC -c RTSignalC.c -o RTSignalC.c.o > RTSignalC.c: In function 'GetPC': > RTSignalC.c:91: error: 'struct mcontext' has no member named 'sc' > make: *** [RTSignalC.c.o] Error 1 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% uname -a > Darwin unknown-00-17-f2-4c-66-5c.home 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > Am I perhaps using a hopeless version of OS X? > > Mika From mika at async.caltech.edu Thu Jul 2 10:55:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 02 Jul 2009 01:55:58 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020855.n628twBs086659@camembert.async.caltech.edu> Jay, all right, GetPC returns 0, and moving on.... [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make Makefile:3312: warning: overriding commands for target `UnixLink.c.o' Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' as M3Buf.ms -o M3Buf.ms.o M3Buf.ms:1610:operands given don't match any known 386 instruction M3Buf.ms:1618:operands given don't match any known 386 instruction make: *** [M3Buf.ms.o] Error 1 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms rep movsl movl %edx, -2184(%ebp) leal -2048(%ebp), %eax movl %eax, -2188(%ebp) movl $509, -2192(%ebp) movl -2184(%ebp), %edi movl -2188(%ebp), %esi movl -2192(%ebp), %ecx rep movsl [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% No this is what I have: [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S2167 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% odd that it would work for you... hmm I wonder, maybe the Xcode needs updating? A little tricky in that case since I don't have console access and am not really a Mac guru. Mika From jay.krell at cornell.edu Thu Jul 2 10:59:02 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 08:59:02 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: Right. Look at I386_DARWIN. It probes for this. You have two choices. - difficult -- put a newline after each lock Their assembler does understand that I recall. - get a newer assembler; that's what I did I386_DARWIN will tell you what version I used, I don't know if older works. or maybe we could/should change cm3cg here. Heck, maybe there's a change in Apple's gcc to merge in. Or maybe, heck, just remove all occurences of lock. You only have one processor, right? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Thu, 2 Jul 2009 01:55:58 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting I386_DARWIN? > > Jay, all right, GetPC returns 0, and moving on.... > > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make > Makefile:3312: warning: overriding commands for target `UnixLink.c.o' > Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' > as M3Buf.ms -o M3Buf.ms.o > M3Buf.ms:1610:operands given don't match any known 386 instruction > M3Buf.ms:1618:operands given don't match any known 386 instruction > make: *** [M3Buf.ms.o] Error 1 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms > rep movsl > movl %edx, -2184(%ebp) > leal -2048(%ebp), %eax > movl %eax, -2188(%ebp) > movl $509, -2192(%ebp) > movl -2184(%ebp), %edi > movl -2188(%ebp), %esi > movl -2192(%ebp), %ecx > rep movsl > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > No this is what I have: > > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers > ProductName: Mac OS X > ProductVersion: 10.4.11 > BuildVersion: 8S2167 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin8 > Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 > Thread model: posix > gcc version 4.0.1 (Apple Computer, Inc. build 5250) > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > odd that it would work for you... hmm I wonder, maybe the Xcode needs > updating? > > A little tricky in that case since I don't have console access and > am not really a Mac guru. > > Mika From jay.krell at cornell.edu Thu Jul 2 11:00:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 09:00:22 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: er, I guess it is rep, not lock, and removing it will break it. Update your assembler or insert newlines.. Sorry. Probably running on 10.5 fixes it too... I tried configuring for older processors, 586, 486, 386 I /think/ none of that worked. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 08:59:02 +0000 > > > Right. Look at I386_DARWIN. > It probes for this. > You have two choices. > - difficult -- put a newline after each lock > Their assembler does understand that I recall. > > > - get a newer assembler; that's what I did > I386_DARWIN will tell you what version I used, I don't know if older works. > > > or maybe we could/should change cm3cg here. > Heck, maybe there's a change in Apple's gcc to merge in. > > > Or maybe, heck, just remove all occurences of lock. > You only have one processor, right? > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Thu, 2 Jul 2009 01:55:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] help booting I386_DARWIN? >> >> Jay, all right, GetPC returns 0, and moving on.... >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >> Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' >> as M3Buf.ms -o M3Buf.ms.o >> M3Buf.ms:1610:operands given don't match any known 386 instruction >> M3Buf.ms:1618:operands given don't match any known 386 instruction >> make: *** [M3Buf.ms.o] Error 1 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms >> rep movsl >> movl %edx, -2184(%ebp) >> leal -2048(%ebp), %eax >> movl %eax, -2188(%ebp) >> movl $509, -2192(%ebp) >> movl -2184(%ebp), %edi >> movl -2188(%ebp), %esi >> movl -2192(%ebp), %ecx >> rep movsl >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> No this is what I have: >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4.11 >> BuildVersion: 8S2167 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >> Using built-in specs. >> Target: i686-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 >> Thread model: posix >> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> odd that it would work for you... hmm I wonder, maybe the Xcode needs >> updating? >> >> A little tricky in that case since I don't have console access and >> am not really a Mac guru. >> >> Mika From jay.krell at cornell.edu Thu Jul 2 11:02:33 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 09:02:33 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: Btw, You don't need "console" access, like to a gui or "xcode". I, and I believe Olaf, used the stripped down "Darwin" that Apple released before it was selling x86 hardware. They don't have current 10.5 builds of that available but they do have 10.4. It works on some "normal" (non-Apple) hardware like some Dell laptops. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 09:00:22 +0000 > > > er, I guess it is rep, not lock, and removing it will break it. Update your assembler or insert newlines.. > Sorry. Probably running on 10.5 fixes it too... > I tried configuring for older processors, 586, 486, 386 I /think/ none of that worked. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] help booting I386_DARWIN? >> Date: Thu, 2 Jul 2009 08:59:02 +0000 >> >> >> Right. Look at I386_DARWIN. >> It probes for this. >> You have two choices. >> - difficult -- put a newline after each lock >> Their assembler does understand that I recall. >> >> >> - get a newer assembler; that's what I did >> I386_DARWIN will tell you what version I used, I don't know if older works. >> >> >> or maybe we could/should change cm3cg here. >> Heck, maybe there's a change in Apple's gcc to merge in. >> >> >> Or maybe, heck, just remove all occurences of lock. >> You only have one processor, right? >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> To: jay.krell at cornell.edu >>> Date: Thu, 2 Jul 2009 01:55:58 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] help booting I386_DARWIN? >>> >>> Jay, all right, GetPC returns 0, and moving on.... >>> >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >>> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >>> Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' >>> as M3Buf.ms -o M3Buf.ms.o >>> M3Buf.ms:1610:operands given don't match any known 386 instruction >>> M3Buf.ms:1618:operands given don't match any known 386 instruction >>> make: *** [M3Buf.ms.o] Error 1 >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms >>> rep movsl >>> movl %edx, -2184(%ebp) >>> leal -2048(%ebp), %eax >>> movl %eax, -2188(%ebp) >>> movl $509, -2192(%ebp) >>> movl -2184(%ebp), %edi >>> movl -2188(%ebp), %esi >>> movl -2192(%ebp), %ecx >>> rep movsl >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >>> >>> No this is what I have: >>> >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >>> ProductName: Mac OS X >>> ProductVersion: 10.4.11 >>> BuildVersion: 8S2167 >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >>> Using built-in specs. >>> Target: i686-apple-darwin8 >>> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 >>> Thread model: posix >>> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >>> >>> odd that it would work for you... hmm I wonder, maybe the Xcode needs >>> updating? >>> >>> A little tricky in that case since I don't have console access and >>> am not really a Mac guru. >>> >>> Mika From lists at darko.org Thu Jul 2 12:16:29 2009 From: lists at darko.org (Darko Volaric) Date: Thu, 2 Jul 2009 12:16:29 +0200 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020654.n626sg3G082786@camembert.async.caltech.edu> References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: <107CE119-1777-4132-A24E-3C6075C625FD@darko.org> It's in Tony's private stash: ftp://ftp.cs.purdue.edu/pub/hosking/m3/ On 02/07/2009, at 8:54 AM, Mika Nystrom wrote: > Hi Modula-3ers (Tony?), > > I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot > archive is broken on the web site... I remember there is some more or > less hidden area where there are more archives, but I don't remember > where? > > Mika From wagner at elegosoft.com Thu Jul 2 12:35:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Jul 2009 12:35:33 +0200 Subject: [M3devel] stepping on your toes In-Reply-To: References: <20090629093610.blv4zraf4ocowk8w@mail.elegosoft.com> <35F93BA7-A05C-4633-89F0-211C5C0256EA@hotmail.com> <20090629110826.mkugfxs884c0owcc@mail.elegosoft.com> <20090701184824.6oeqk8cdbggw8owc@mail.elegosoft.com> <20090702082756.e5lkauyzfo44000k@mail.elegosoft.com> Message-ID: <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> Quoting Jay : > Olaf, the ws packages contain source and unshipped outputs, right? > What do you think is the point of these archives vs. binary-only and > source-only archives? I have ideas but I don't want to lead you. The idea was to reduce the number of packages, as M3 does not really support the separation of source and derived files for binary packages. So why not just enrich the source with just the products needed for shipping? This is sort of the smallest supported _M3_-binary package. Both system-dependent source and binary packages can be based on the same collection of ws packages. Traditionally CM3 offered only sources packages except for the minimal installation archive. There were lots of problems with o people understanding how to compile the source and o actual compilation errors due to miscellaneous causes People wanted something that is easy to install (without using lots of complex scripts). So I extended the standard cm3 builder so it can be used for such an installation. These are exactly the ws archives. M3 source and derived files which are needed for shipping an M3 package, but not more. I found that rather nice. >> core vs. min vs. boot > > Yeah I was equating min with boot. > Still, as to what is "minimal" vs. "useful", not clear. For example, > "minimal" can be reduced by not allowing for static linking. The > .sa files add a lot of size. But that is slightly less useful, so > someone who wants to make standalone programs. > And min still varies in definition depending on one's prediction of > the future. > > Even then there are multiple definitions here: > boot for the current matching release > or boot for the next release? > > If it is for the matching release, no problem predicting the future, > it is just the assembly code for cm3, and no provision for creating > a package store with any contents, until user also gets source and > builds it. I have in mind the old 3.6 release form, though we can't > quite emulate it, now that the builder is in M3 and not C. > > I'd like to look into this cross building of boot/assembly releases, > though first some other things.. The whole cross-compilation topic is not really relevant for a release IMO. There are very few people who actually want to do such things ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Jul 2 15:42:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 09:42:31 -0400 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: <073CA2E9-4E98-449E-B725-E478A0F8D20D@cs.purdue.edu> Best to upgrade xcode. On 2 Jul 2009, at 04:59, Jay wrote: > > Right. Look at I386_DARWIN. > It probes for this. > You have two choices. > - difficult -- put a newline after each lock > Their assembler does understand that I recall. > > > - get a newer assembler; that's what I did > I386_DARWIN will tell you what version I used, I don't know if > older works. > > > or maybe we could/should change cm3cg here. > Heck, maybe there's a change in Apple's gcc to merge in. > > > Or maybe, heck, just remove all occurences of lock. > You only have one processor, right? > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Thu, 2 Jul 2009 01:55:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] help booting I386_DARWIN? >> >> Jay, all right, GetPC returns 0, and moving on.... >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >> Makefile:687: warning: ignoring old commands for target >> `UnixLink.c.o' >> as M3Buf.ms -o M3Buf.ms.o >> M3Buf.ms:1610:operands given don't match any known 386 instruction >> M3Buf.ms:1618:operands given don't match any known 386 instruction >> make: *** [M3Buf.ms.o] Error 1 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n >> 1610,1618p M3Buf.ms >> rep movsl >> movl %edx, -2184(%ebp) >> leal -2048(%ebp), %eax >> movl %eax, -2188(%ebp) >> movl $509, -2192(%ebp) >> movl -2184(%ebp), %edi >> movl -2188(%ebp), %esi >> movl -2192(%ebp), %ecx >> rep movsl >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> No this is what I have: >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4.11 >> BuildVersion: 8S2167 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >> Using built-in specs. >> Target: i686-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure >> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man >> --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/ >> ^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- >> build=powerpc-apple-darwin8 --with-arch=pentium-m --with- >> tune=prescott --program-prefix= --host=i686-apple-darwin8 -- >> target=i686-apple-darwin8 >> Thread model: posix >> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> odd that it would work for you... hmm I wonder, maybe the Xcode needs >> updating? >> >> A little tricky in that case since I don't have console access and >> am not really a Mac guru. >> >> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 2 17:08:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 2 Jul 2009 11:08:17 -0400 Subject: [M3devel] stepping on your toes In-Reply-To: <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> References: <20090629093610.blv4zraf4ocowk8w@mail.elegosoft.com> <35F93BA7-A05C-4633-89F0-211C5C0256EA@hotmail.com> <20090629110826.mkugfxs884c0owcc@mail.elegosoft.com> <20090701184824.6oeqk8cdbggw8owc@mail.elegosoft.com> <20090702082756.e5lkauyzfo44000k@mail.elegosoft.com> <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> Message-ID: <20090702150816.GC21089@topoi.pooq.com> On Thu, Jul 02, 2009 at 12:35:33PM +0200, Olaf Wagner wrote: > Quoting Jay : > > >Olaf, the ws packages contain source and unshipped outputs, right? > >What do you think is the point of these archives vs. binary-only and > > source-only archives? I have ideas but I don't want to lead you. > > The idea was to reduce the number of packages, as M3 does not > really support the separation of source and derived files for binary > packages. So why not just enrich the source with just the products > needed for shipping? This is sort of the smallest supported _M3_-binary > package. > > Both system-dependent source and binary packages can be based on the > same collection of ws packages. > > Traditionally CM3 offered only sources packages except for the minimal > installation archive. There were lots of problems with > > o people understanding how to compile the source and > o actual compilation errors due to miscellaneous causes > > People wanted something that is easy to install (without using lots > of complex scripts). So I extended the standard cm3 builder so it can > be used for such an installation. Just a point of interest. Debian has a number of apparently proprietary packages -- such as the one for nvidia drivers. What they do is, during installation, connect to the nvidia web site to download the driver, then install the result of downloading. So a significane amount of very package-dependent work can be done during installation -- such as compiling. It may not be in the spirit of binary packages, but can be made to work automatically. What this doesn't do is enable multiple binary packages to be built from a single source -- which Debian also does frmo time to time, but at headquarters, not in apt or aptitude. > > These are exactly the ws archives. M3 source and derived files which > are needed for shipping an M3 package, but not more. I found that > rather nice. > > > >>core vs. min vs. boot > > > >Yeah I was equating min with boot. > >Still, as to what is "minimal" vs. "useful", not clear. For example, > > "minimal" can be reduced by not allowing for static linking. The > >.sa files add a lot of size. But that is slightly less useful, so > >someone who wants to make standalone programs. > >And min still varies in definition depending on one's prediction of > >the future. > > > >Even then there are multiple definitions here: > > boot for the current matching release > > or boot for the next release? > > > >If it is for the matching release, no problem predicting the future, > > it is just the assembly code for cm3, and no provision for creating > > a package store with any contents, until user also gets source and > >builds it. I have in mind the old 3.6 release form, though we can't > >quite emulate it, now that the builder is in M3 and not C. > > > >I'd like to look into this cross building of boot/assembly releases, > > though first some other things.. > > The whole cross-compilation topic is not really relevant for a > release IMO. There are very few people who actually want to do > such things ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hosking at cs.purdue.edu Thu Jul 2 17:43:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:43:35 -0400 Subject: [M3devel] Error in building cm3 Message-ID: I've just updated m3-sys/cm3 and now get the following error when building. What gives? --- building in SOLgnu --- ignoring ../src/m3overrides "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: undefined variable: ROOT --procedure-- -line- -file--- include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile 5 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/ SOLgnu/m3make.args Fatal Error: package build failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 17:49:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Message-ID: Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. From hosking at cs.purdue.edu Thu Jul 2 17:51:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:51:30 -0400 Subject: [M3devel] UnixLink.c Message-ID: It seems fundamentally broken to me that m3-sys/cm3 should be doing all this copying of UnixLink just so some previous m3core can be linked to. Surely, when bootstrapping you need to compile a *new* m3core against which cm3 wil link. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 17:54:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:54:51 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: If I define ROOT then I get the following error. I think this all needs reverting! --- building in SOLgnu --- ignoring ../src/m3overrides "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ Common/UnixLink.c" to "./UnixLink.c": errno=2 --procedure-- -line- -file--- cp_if -- include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/ SOLgnu/m3make.args Fatal Error: package build failed n On 2 Jul 2009, at 11:49, Tony Hosking wrote: > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 18:19:03 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:19:03 +0000 Subject: [M3devel] UnixLink.c In-Reply-To: References: Message-ID: > Surely, when bootstrapping you need to > compile a *new* m3core against which cm3 wil link. Nope. As long as we have those "release" tinderbox builds that build from 5.4 m3core... Remove that requirement and I'd gladly clean this up. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:51:30 -0400 > Subject: [M3devel] UnixLink.c > > It seems fundamentally broken to me that m3-sys/cm3 should be doing all this copying of UnixLink just so some previous m3core can be linked to. Surely, when bootstrapping you need to compile a *new* m3core against which cm3 wil link. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > From jay.krell at cornell.edu Thu Jul 2 18:19:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:19:49 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: > Seems broken to me to depend on > the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > From jay.krell at cornell.edu Thu Jul 2 18:21:07 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:21:07 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Are you up to date in m3-libs/m3core? Lots of builds have succeeded with this.. It isn't great, but that requirement to build from previous 5.4 release.. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Thu, 2 Jul 2009 11:54:51 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > If I define ROOT then I get the following error. I think this all needs reverting! > > --- building in SOLgnu --- > > ignoring ../src/m3overrides > > "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/Common/UnixLink.c" to "./UnixLink.c": errno=2 > > --procedure-- -line- -file--- > cp_if -- > include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile > 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > > Fatal Error: package build failed > n > > On 2 Jul 2009, at 11:49, Tony Hosking wrote: > > Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. > > From hosking at cs.purdue.edu Thu Jul 2 18:40:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 12:40:18 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: I'm not talking about m3overrides. That is a arguably a special- purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: > >> Seems broken to me to depend on >> the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 18:42:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 12:42:52 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Whether or not I am up-to-date I dislike the whole ROOT dependence for standard builds! On 2 Jul 2009, at 12:21, Jay wrote: > > Are you up to date in m3-libs/m3core? > Lots of builds have succeeded with this.. > It isn't great, but that requirement to build from previous 5.4 > release.. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 2 Jul 2009 11:54:51 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ROOT >> >> If I define ROOT then I get the following error. I think this all >> needs reverting! >> >> --- building in SOLgnu --- >> >> ignoring ../src/m3overrides >> >> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: >> quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ >> Common/UnixLink.c" to "./UnixLink.c": errno=2 >> >> --procedure-- -line- -file--- >> cp_if -- >> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >> m3makefile >> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >> >> Fatal Error: package build failed >> n >> >> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as >> it sets that structure in stone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 18:55:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:55:16 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: As long as there is a need to work with older m3core, there will be hacks.. This stuff provides a significant value. Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > From jay.krell at cornell.edu Thu Jul 2 19:13:05 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 17:13:05 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Btw, I think setting an environment variable that points to the root of the source tree is a pretty small cost to pay, for almost anything. ROOT is a bit generic I realize. It is worse to be copying files around, I admit, and I'm doing that too. Another option is to copy /and/ commit the files, perhaps to sysutils, since we don't have to work with an old sysutils. This is the same sort of problem, you'll recall, that plagued making waitpid users not sleep() on pthreads platforms. There are still small hacks in place for that -- pretty small now, like, assuming we are on pthreads and not sleeping, to the detriment of user threads implementations. CM3_ROOT should work, but that might depend on your config file. I am strongly tempted to have cm3 poke around in the CVS directories and figure it out itself, as so many builds are run with .sh code that does roughly that. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ROOT > Date: Thu, 2 Jul 2009 16:55:16 +0000 > > > As long as there is a need to work with older m3core, there will be hacks.. > This stuff provides a significant value. > Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. > > > With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. > > As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 12:40:18 -0400 >> >> I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 2 Jul 2009, at 12:19, Jay wrote: >> >> >> Seems broken to me to depend on >> the source directory structure >> >> Like m3overrides? But yes, I agree. >> m3overrides seems broken too. >> >> - Jay >> >> >> >> >> >> >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> >> From jay.krell at cornell.edu Thu Jul 2 19:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 17:14:43 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: [truncated..] ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ROOT > Date: Thu, 2 Jul 2009 17:13:05 +0000 > > > Btw, I think setting an environment variable that points to the root of the source tree is a pretty small cost to pay, for almost anything. > ROOT is a bit generic I realize. > > > It is worse to be copying files around, I admit, and I'm doing that too. > Another option is to copy /and/ commit the files, perhaps to sysutils, since we don't have to work with an old sysutils. This is the same sort of problem, you'll recall, that plagued making waitpid users not sleep() on pthreads platforms. There are still small hacks in place for that -- pretty small now, like, assuming we are on pthreads and not sleeping, to the detriment of user threads implementations. > > > CM3_ROOT should work, but that might depend on your config file. > > I am strongly tempted to have cm3 poke around in the CVS directories and figure it out itself, as so many builds are run with .sh code that does roughly that. > > - Jay > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 16:55:16 +0000 >> >> >> As long as there is a need to work with older m3core, there will be hacks.. >> This stuff provides a significant value. >> Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >> >> >> With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. >> >> As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. >> >> >> - Jay >> >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>> >>> I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 2 Jul 2009, at 12:19, Jay wrote: >>> >>> >>> Seems broken to me to depend on >>> the source directory structure >>> >>> Like m3overrides? But yes, I agree. >>> m3overrides seems broken too. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>> Subject: [M3devel] ROOT >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as it >>> sets that structure in stone. >>> >>> >>> From hosking at cs.purdue.edu Thu Jul 2 19:47:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:47:44 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> On 2 Jul 2009, at 12:55, Jay wrote: > As long as there is a need to work with older m3core, there will be > hacks.. But why would you compile a new cm3 with an old m3core? > This stuff provides a significant value. > Before, the runpaths recorded would be a directory per dependent > shared object -- the directory in the package store. And the > runpaths were not machine portable -- if you install to a different > location, which is debatable, maybe everyone should be stuck with / > usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > With the hard links, people don't have to set LD_LIBRARY_PATH and > everyone can pick their own install location. Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? > As well the temporary staging location for a distribution is not > recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but / > tmp/something. I'd really like to hear opinions on this from others. > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 12:40:18 -0400 >> >> I'm not talking about m3overrides. That is a arguably a special- >> purpose hack. We shouldn't layer a hack into the *normal* build >> process. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 2 Jul 2009, at 12:19, Jay wrote: >> >> >> Seems broken to me to depend on >> the source directory structure >> >> Like m3overrides? But yes, I agree. >> m3overrides seems broken too. >> >> - Jay >> >> >> >> >> >> >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> >> From hosking at cs.purdue.edu Thu Jul 2 19:51:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:51:00 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <314CD2AE-A9E0-4D23-BDEC-DFD776DB8FB7@cs.purdue.edu> On 2 Jul 2009, at 13:13, Jay wrote: > Btw, I think setting an environment variable that points to the root > of the source tree is a pretty small cost to pay, for almost anything. But, again, this hardcodes the source tree structure into the configuration files, which I really hate. > ROOT is a bit generic I realize. > > > It is worse to be copying files around, I admit, and I'm doing that > too. Right. > Another option is to copy /and/ commit the files, perhaps to > sysutils, since we don't have to work with an old sysutils. This is > the same sort of problem, you'll recall, that plagued making waitpid > users not sleep() on pthreads platforms. There are still small hacks > in place for that -- pretty small now, like, assuming we are on > pthreads and not sleeping, to the detriment of user threads > implementations. > > > CM3_ROOT should work, but that might depend on your config file. > > I am strongly tempted to have cm3 poke around in the CVS directories > and figure it out itself, as so many builds are run with .sh code > that does roughly that. Perhaps you can step back and provide a high-level rationale for what is needed, and how best to accomplish it. I've lost the big picture here. > > - Jay > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 16:55:16 +0000 >> >> >> As long as there is a need to work with older m3core, there will be >> hacks.. >> This stuff provides a significant value. >> Before, the runpaths recorded would be a directory per dependent >> shared object -- the directory in the package store. And the >> runpaths were not machine portable -- if you install to a different >> location, which is debatable, maybe everyone should be stuck with / >> usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >> >> >> With the hard links, people don't have to set LD_LIBRARY_PATH and >> everyone can pick their own install location. >> >> As well the temporary staging location for a distribution is not >> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >> but /tmp/something. >> >> >> - Jay >> >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>> >>> I'm not talking about m3overrides. That is a arguably a special- >>> purpose hack. We shouldn't layer a hack into the *normal* build >>> process. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 2 Jul 2009, at 12:19, Jay wrote: >>> >>> >>> Seems broken to me to depend on >>> the source directory structure >>> >>> Like m3overrides? But yes, I agree. >>> m3overrides seems broken too. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>> Subject: [M3devel] ROOT >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as it >>> sets that structure in stone. >>> >>> >>> From hosking at cs.purdue.edu Thu Jul 2 19:51:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:51:36 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> PS I don't see the truncated e-mails when I get them -- must be something broken on your end. On 2 Jul 2009, at 13:14, Jay wrote: > > [truncated..] > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 17:13:05 +0000 >> >> >> Btw, I think setting an environment variable that points to the >> root of the source tree is a pretty small cost to pay, for almost >> anything. >> ROOT is a bit generic I realize. >> >> >> It is worse to be copying files around, I admit, and I'm doing that >> too. >> Another option is to copy /and/ commit the files, perhaps to >> sysutils, since we don't have to work with an old sysutils. This is >> the same sort of problem, you'll recall, that plagued making >> waitpid users not sleep() on pthreads platforms. There are still >> small hacks in place for that -- pretty small now, like, assuming >> we are on pthreads and not sleeping, to the detriment of user >> threads implementations. >> >> >> CM3_ROOT should work, but that might depend on your config file. >> >> I am strongly tempted to have cm3 poke around in the CVS >> directories and figure it out itself, as so many builds are run >> with .sh code that does roughly that. >> >> - Jay >> >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 16:55:16 +0000 >>> >>> >>> As long as there is a need to work with older m3core, there will >>> be hacks.. >>> This stuff provides a significant value. >>> Before, the runpaths recorded would be a directory per dependent >>> shared object -- the directory in the package store. And the >>> runpaths were not machine portable -- if you install to a >>> different location, which is debatable, maybe everyone should be >>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >>> >>> >>> With the hard links, people don't have to set LD_LIBRARY_PATH and >>> everyone can pick their own install location. >>> >>> As well the temporary staging location for a distribution is not >>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >>> but /tmp/something. >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>>> CC: m3devel at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: [M3devel] ROOT >>>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>>> >>>> I'm not talking about m3overrides. That is a arguably a special- >>>> purpose hack. We shouldn't layer a hack into the *normal* build >>>> process. >>>> >>>> >>>> Antony Hosking | Associate Professor | Computer Science | Purdue >>>> University >>>> 305 N. University Street | West Lafayette | IN 47907 | USA >>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>>> >>>> >>>> >>>> >>>> On 2 Jul 2009, at 12:19, Jay wrote: >>>> >>>> >>>> Seems broken to me to depend on >>>> the source directory structure >>>> >>>> Like m3overrides? But yes, I agree. >>>> m3overrides seems broken too. >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: m3devel at elegosoft.com >>>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>>> Subject: [M3devel] ROOT >>>> >>>> Where did variable ROOT come from? Do I really need to define it? >>>> Seems broken to me to depend on the source directory structure as >>>> it >>>> sets that structure in stone. >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 19:53:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:53:07 -0400 Subject: [M3devel] ROOT In-Reply-To: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> Message-ID: <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> That sounds plausible. Is there anything in the current setup that depends on the .so files being in pkg instead of lib? On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > How about we put .so files only in lib and not in pkg? Or symlink > from pkg to lib instead of how it used to be the other way around? > Those would also fix all this. > > - Jay (phone) > > On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> >> Are you up to date in m3-libs/m3core? >> Lots of builds have succeeded with this.. >> It isn't great, but that requirement to build from previous 5.4 >> release.. >> >> - Jay >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 2 Jul 2009 11:54:51 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] ROOT >>> >>> If I define ROOT then I get the following error. I think this all >>> needs reverting! >>> >>> --- building in SOLgnu --- >>> >>> ignoring ../src/m3overrides >>> >>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line >>> 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/ >>> unix/Common/UnixLink.c" to "./UnixLink.c": errno=2 >>> >>> --procedure-- -line- -file--- >>> cp_if -- >>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >>> m3makefile >>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >>> >>> Fatal Error: package build failed >>> n >>> >>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as >>> it sets that structure in stone. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 2 20:04:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Jul 2009 20:04:36 +0200 Subject: [M3devel] ROOT In-Reply-To: <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> Message-ID: <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Quoting Tony Hosking : > That sounds plausible. Is there anything in the current setup that > depends on the .so files being in pkg instead of lib? I don't think so offhand. But I must admit that I've lost the overview in this area, too :-/ Olaf > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > >> How about we put .so files only in lib and not in pkg? Or symlink >> from pkg to lib instead of how it used to be the other way around? >> Those would also fix all this. >> >> - Jay (phone) >> >> On Jul 2, 2009, at 9:21 AM, Jay wrote: >> >>> >>> Are you up to date in m3-libs/m3core? >>> Lots of builds have succeeded with this.. >>> It isn't great, but that requirement to build from previous 5.4 release.. >>> >>> - Jay >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] ROOT >>>> >>>> If I define ROOT then I get the following error. I think this all >>>> needs reverting! >>>> >>>> --- building in SOLgnu --- >>>> >>>> ignoring ../src/m3overrides >>>> >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line >>>> 12: quake runtime error: unable to copy >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to >>>> "./UnixLink.c": errno=2 >>>> >>>> --procedure-- -line- -file--- >>>> cp_if -- >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >>>> >>>> Fatal Error: package build failed >>>> n >>>> >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >>>> >>>> Where did variable ROOT come from? Do I really need to define it? >>>> Seems broken to me to depend on the source directory structure >>>> as it sets that structure in stone. >>>> >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 2 20:09:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 11:09:40 -0700 Subject: [M3devel] ROOT In-Reply-To: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> Message-ID: <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> The ones sent directly to people aren't truncated, only when they go through m3devel. - Jay (phone) On Jul 2, 2009, at 10:51 AM, Tony Hosking wrote: > PS I don't see the truncated e-mails when I get them -- must be > something broken on your end. > > On 2 Jul 2009, at 13:14, Jay wrote: > >> >> [truncated..] >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 17:13:05 +0000 >>> >>> >>> Btw, I think setting an environment variable that points to the >>> root of the source tree is a pretty small cost to pay, for almost >>> anything. >>> ROOT is a bit generic I realize. >>> >>> >>> It is worse to be copying files around, I admit, and I'm doing >>> that too. >>> Another option is to copy /and/ commit the files, perhaps to >>> sysutils, since we don't have to work with an old sysutils. This >>> is the same sort of problem, you'll recall, that plagued making >>> waitpid users not sleep() on pthreads platforms. There are still >>> small hacks in place for that -- pretty small now, like, assuming >>> we are on pthreads and not sleeping, to the detriment of user >>> threads implementations. >>> >>> >>> CM3_ROOT should work, but that might depend on your config file. >>> >>> I am strongly tempted to have cm3 poke around in the CVS >>> directories and figure it out itself, as so many builds are run >>> with .sh code that does roughly that. >>> >>> - Jay >>> >>> >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] ROOT >>>> Date: Thu, 2 Jul 2009 16:55:16 +0000 >>>> >>>> >>>> As long as there is a need to work with older m3core, there will >>>> be hacks.. >>>> This stuff provides a significant value. >>>> Before, the runpaths recorded would be a directory per dependent >>>> shared object -- the directory in the package store. And the >>>> runpaths were not machine portable -- if you install to a >>>> different location, which is debatable, maybe everyone should be >>>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >>>> >>>> >>>> With the hard links, people don't have to set LD_LIBRARY_PATH and >>>> everyone can pick their own install location. >>>> >>>> As well the temporary staging location for a distribution is not >>>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >>>> but /tmp/something. >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ________________________________ >>>>> CC: m3devel at elegosoft.com >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Subject: Re: [M3devel] ROOT >>>>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>>>> >>>>> I'm not talking about m3overrides. That is a arguably a special- >>>>> purpose hack. We shouldn't layer a hack into the *normal* build >>>>> process. >>>>> >>>>> >>>>> Antony Hosking | Associate Professor | Computer Science | Purdue >>>>> University >>>>> 305 N. University Street | West Lafayette | IN 47907 | USA >>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>>>> >>>>> >>>>> >>>>> >>>>> On 2 Jul 2009, at 12:19, Jay wrote: >>>>> >>>>> >>>>> Seems broken to me to depend on >>>>> the source directory structure >>>>> >>>>> Like m3overrides? But yes, I agree. >>>>> m3overrides seems broken too. >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>>>> Subject: [M3devel] ROOT >>>>> >>>>> Where did variable ROOT come from? Do I really need to define it? >>>>> Seems broken to me to depend on the source directory structure >>>>> as it >>>>> sets that structure in stone. >>>>> >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Thu Jul 2 20:31:45 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 14:31:45 -0400 Subject: [M3devel] ROOT In-Reply-To: <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> Message-ID: <4A4CC4CE.1E75.00D7.1@scires.com> I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Thu Jul 2 20:41:27 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:41:27 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: Before I explain, more options: copy and commit the source to cm3 is viable heck, use a relative instead of absolute from ROOT go back to the old way (I'll explain) There is also the option to relink or "fixup" upon ship and/or install. Some platforms have a "fixup" utility for exactly "these reasons". MacOS X has one. The question is: How does program foo find libbar.so? At runtime. How does libbar.so find libfoo.so? There are a bewildering array of choices. They are combinable. It varies somewhat from platform by platform, but not much really. The main options are: 1: A full path written into program foo or libbar pointing to e.g. /usr/lib/libfoo.so. Actually this is usually separate libfoo.so and a list of directories that apply to all .so files. There isn't generally a matching up of directory to file, I think, but a "search path" aka "run path". 2: A relative path written into program foo or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. Again, the directories are split from the files. MacOS X doesn't have $ORIGIN by that name, but it has three similar things, like @executable_path. @executable_path goes way back and is presumably relative to the primary main executable. There are two other similar options. One is new in 10.5. Presumably one is relative to the reference. And maybe one is some concatenation of all directories anything found in so far? I don't know. The documenation was not clear to me. NetBSD prior to 5.0 doesn't have $ORIGIN. NT searches $PATH always. We put the .dlls in bin. Cygwin same. Approximately all other systems seem to support about the same $ORIGIN feature: OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?) The MacOS X feature is close enough to lump in. 3: Search $LD_LIBRARY_PATH or similar. This has a few different names. LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. Now, our historical implementation was - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, a path for every dependency The file formats are generally such that there are leaf file names separate from an array of directories to look in. A "normal" non-Modula-3 program would generally I assume have a prety small such array of directories. A "normal" Modula-3 program would have a fairly large array. As well, doing builds for distribution would often leave you with /tmp/cm3 which is a possible security problem. This definitely did occur. Now, again, there are many options, and they can be combined. Portability is perhaps a concern, but perhaps not so much, given today's landscape. Now, if we are to use relative paths, well, my understanding is that the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib, and not /usr/local/cm3/pkg/foo/linux etc. This way, files in lib and bin can point to $ORIGIN/../lib. Now, keep in mind, that unshipped binaries sometimes people like to work, as well, perhaps also programs (not shared libraies, as far as I know) buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. I know cm3 sits in there, though that copy isn't used. I make no account for binaries buried in the package store. I do make some account for unshipped binaries. By default the run paths we are recording in current config files are $ORIGIN/../lib:/usr/local/cm3/lib Not a bunch of paths into pkg, just two entries. The "security" issue still is present by default. But the run path is "prettier" and probably more efficient. When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3). This is controled by an environment variable, which I set in Olaf's scripts, but oops I think I set it too late. I'll fix that very very soon. To recap: - full paths - relative paths from $ORIGIN - LD_LIBRARY_PATH They each have advantages and disadvantages. $ORIGIN provides for a "movable" install. I can install to /usr/local/cm3, you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH. However if I want to move just some of the files, not the whole binary tree together, then $ORIGIN breaks down. If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do. You are left with full paths or LD_LIBRARY_PATH. Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such. Look on birch for example, it is /usr/local/cm3/lib. That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there. This demonstrated another problem in this area! $ORIGIN keeps things more tightly together, which you often want, sometimes might not not. LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not. I figure tightly point is the more common, but imagine if you just want to replace one file. Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install this way.) So, here now I'm rambling. I've laid out the options and /some/ of the disadvantages/advantages. There is no perfect solution, and the various solutions are combinable. I find combining them though, I start to get confused. Because you end up in a "probing" situation and you start wondering which supercedes which, and you just hope there aren't any "duplicates" so that the probe order is mostly moot (assuming there remain no duplicates). Somewhat clear? You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and investigate the various options and their effects. Solaris has a very nice and verbose ldd form. Now, the files in pkg. I consider it somewhat philosophically significant that "everything is in pkg". There is a well structured "repository" not a randomly organized bunch of files. I think. Maybe this is just a suggestion? You know, if they are hardlinks and we don't really use the ones in pkg, is there a point? Or, on the other hand, is the philosophy a big deal and we should go back to lib symlinking to pkg to appease the philosophy? "ship/install" certainly "likes" to put things in pkg. I don't think the option of using lib and not pkg is doable without builder changes. But that is doable. A few other folks here did pipe up some on this in the recent past and I think there was kinda sorta consensus that the old ways were not great (particularly 1) the big runpath 2) the runpath into /tmp) and the new ways maybe better, but I admit there was no clear consensus. I acted somewhat unilaterally. You know, I'm impatient and arrogant so... and Tinderbox is there to cause some restraint. There was definitely pushback on wanting unshipped binaries to keep working, which they largely do as a result of the discussion/pushback. As well, any unshipped binaries that we know we use in the build, like PklFonts, stubgen, m3bundle, we build standalone, to evade/avoid problems here, since $ORIGIN/../lib won't work and the full paths are meant to be omitted. I consider this not great. I think, really, we should be able to dynamically link everything really, including cm3. I don't think we should static link just to make up for the need for a backup. There are plenty of backups available and you can make plenty more. However this will have to wait and probably take more arguing and maybe demonstration of its viability. I will require some work to make work anyway. At one point I was confused about the need for static linking so accepted it strongly. Now I don't see it. If you just need backups, again, they exist, and you can make more. Static linking isn't imho a substitute for backups. There are technical problems to be solved though. Could be that these issues are related though. If your backup might load the wrong m3core.so too easily, making it not a very reliable backup, static linking could mitigate that. But $origin seems like a good mitigation. I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath. That way you can just put everything in one messy but easier to move/copy directory. - Jay > Date: Thu, 2 Jul 2009 20:04:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > Quoting Tony Hosking : > > > That sounds plausible. Is there anything in the current setup that > > depends on the .so files being in pkg instead of lib? > > I don't think so offhand. But I must admit that I've lost the overview > in this area, too :-/ > > Olaf > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > >> How about we put .so files only in lib and not in pkg? Or symlink > >> from pkg to lib instead of how it used to be the other way around? > >> Those would also fix all this. > >> > >> - Jay (phone) > >> > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> > >>> > >>> Are you up to date in m3-libs/m3core? > >>> Lots of builds have succeeded with this.. > >>> It isn't great, but that requirement to build from previous 5.4 release.. > >>> > >>> - Jay > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] ROOT > >>>> > >>>> If I define ROOT then I get the following error. I think this all > >>>> needs reverting! > >>>> > >>>> --- building in SOLgnu --- > >>>> > >>>> ignoring ../src/m3overrides > >>>> > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > >>>> 12: quake runtime error: unable to copy > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > >>>> "./UnixLink.c": errno=2 > >>>> > >>>> --procedure-- -line- -file--- > >>>> cp_if -- > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > >>>> > >>>> Fatal Error: package build failed > >>>> n > >>>> > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > >>>> > >>>> Where did variable ROOT come from? Do I really need to define it? > >>>> Seems broken to me to depend on the source directory structure > >>>> as it sets that structure in stone. > >>>> > >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:48:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:48:00 +0000 Subject: [M3devel] ROOT In-Reply-To: <4A4CC4CE.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I'm completely agree that ROOT is too generic for an environment variable and it NOT required. It IS a quake variable though, and has long been. Nothing new there. At least if you ever use overrides. CM3_ROOT is in fact the other name. There are also quake variables INSTALLROOT and/or INSTALL_ROOT, I get those confused, and the environment variable CM3_INSTALL. I'm not a huge fan of the exact names actually, but they all/mostly were already there. I would have liked CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. I find ROOT and CM3_ROOT too ambiguous. But again, ROOT is quite old, to refer to the source and INSTALL_ROOT or INSTALLROOT is quite old to refer to the install. Hopefully my other mail will help clear this up. I agree this is all not easy to communicate. To some extent I just have to depend on people knowing that "How a file finds the .so files it uses?" Is a well known long standing dilemna and if you search the web you can find many people trying to explain aspects of it. Maybe I should put together some examples. However, I think I did. I think the ChangeLog explains it well. Let me check. no..must have been somewhere else. Anyway, search the web for $origin, ldd, -runpath, etc.... Try wading through the Apple, Sun, GNU/Linux ld man pages. They aren't pretty, I grant. I'll try to put together some examples maybe soon, maybe. Solaris has the nicer more verbose ldd and I'll be away over the weekend so no Solaris. I'd also like to do other Modula-3 work: 64 bit file sizes on all platforms I'm at least going to try. This might cascade too far and break a lot of things, since INTEGER and LONGINT cannot be freely intermixed, you can't even assign an INTEGER to a LONGINT! Merge gcc-interix with gcc. It turns out this is quite small. Enable the "portable runpaths" in Olaf's scripts (related to all this). I put the lines in slightly too far down in the code, oops. - Jay Date: Thu, 2 Jul 2009 14:31:45 -0400 From: rcolebur at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:51:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:51:22 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: darnit I need to be more careful. program -- not a shared library binary -- program or shared library in some contexts, but I used it below also to mean program shared library -- .dll, .so, etc. "I make no account for binaries in the pkg store" -- I meant programs. Darn I need to write this better...hopefully some of it will come through... - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 18:41:27 +0000 Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Before I explain, more options: copy and commit the source to cm3 is viable heck, use a relative instead of absolute from ROOT go back to the old way (I'll explain) There is also the option to relink or "fixup" upon ship and/or install. Some platforms have a "fixup" utility for exactly "these reasons". MacOS X has one. The question is: How does program foo find libbar.so? At runtime. How does libbar.so find libfoo.so? There are a bewildering array of choices. They are combinable. It varies somewhat from platform by platform, but not much really. The main options are: 1: A full path written into program foo or libbar pointing to e.g. /usr/lib/libfoo.so. Actually this is usually separate libfoo.so and a list of directories that apply to all .so files. There isn't generally a matching up of directory to file, I think, but a "search path" aka "run path". 2: A relative path written into program foo or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. Again, the directories are split from the files. MacOS X doesn't have $ORIGIN by that name, but it has three similar things, like @executable_path. @executable_path goes way back and is presumably relative to the primary main executable. There are two other similar options. One is new in 10.5. Presumably one is relative to the reference. And maybe one is some concatenation of all directories anything found in so far? I don't know. The documenation was not clear to me. NetBSD prior to 5.0 doesn't have $ORIGIN. NT searches $PATH always. We put the .dlls in bin. Cygwin same. Approximately all other systems seem to support about the same $ORIGIN feature: OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?) The MacOS X feature is close enough to lump in. 3: Search $LD_LIBRARY_PATH or similar. This has a few different names. LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. Now, our historical implementation was - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, a path for every dependency The file formats are generally such that there are leaf file names separate from an array of directories to look in. A "normal" non-Modula-3 program would generally I assume have a prety small such array of directories. A "normal" Modula-3 program would have a fairly large array. As well, doing builds for distribution would often leave you with /tmp/cm3 which is a possible security problem. This definitely did occur. Now, again, there are many options, and they can be combined. Portability is perhaps a concern, but perhaps not so much, given today's landscape. Now, if we are to use relative paths, well, my understanding is that the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib, and not /usr/local/cm3/pkg/foo/linux etc. This way, files in lib and bin can point to $ORIGIN/../lib. Now, keep in mind, that unshipped binaries sometimes people like to work, as well, perhaps also programs (not shared libraies, as far as I know) buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. I know cm3 sits in there, though that copy isn't used. I make no account for binaries buried in the package store. I do make some account for unshipped binaries. By default the run paths we are recording in current config files are $ORIGIN/../lib:/usr/local/cm3/lib Not a bunch of paths into pkg, just two entries. The "security" issue still is present by default. But the run path is "prettier" and probably more efficient. When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3). This is controled by an environment variable, which I set in Olaf's scripts, but oops I think I set it too late. I'll fix that very very soon. To recap: - full paths - relative paths from $ORIGIN - LD_LIBRARY_PATH They each have advantages and disadvantages. $ORIGIN provides for a "movable" install. I can install to /usr/local/cm3, you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH. However if I want to move just some of the files, not the whole binary tree together, then $ORIGIN breaks down. If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do. You are left with full paths or LD_LIBRARY_PATH. Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such. Look on birch for example, it is /usr/local/cm3/lib. That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there. This demonstrated another problem in this area! $ORIGIN keeps things more tightly together, which you often want, sometimes might not not. LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not. I figure tightly point is the more common, but imagine if you just want to replace one file. Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install this way.) So, here now I'm rambling. I've laid out the options and /some/ of the disadvantages/advantages. There is no perfect solution, and the various solutions are combinable. I find combining them though, I start to get confused. Because you end up in a "probing" situation and you start wondering which supercedes which, and you just hope there aren't any "duplicates" so that the probe order is mostly moot (assuming there remain no duplicates). Somewhat clear? You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and investigate the various options and their effects. Solaris has a very nice and verbose ldd form. Now, the files in pkg. I consider it somewhat philosophically significant that "everything is in pkg". There is a well structured "repository" not a randomly organized bunch of files. I think. Maybe this is just a suggestion? You know, if they are hardlinks and we don't really use the ones in pkg, is there a point? Or, on the other hand, is the philosophy a big deal and we should go back to lib symlinking to pkg to appease the philosophy? "ship/install" certainly "likes" to put things in pkg. I don't think the option of using lib and not pkg is doable without builder changes. But that is doable. A few other folks here did pipe up some on this in the recent past and I think there was kinda sorta consensus that the old ways were not great (particularly 1) the big runpath 2) the runpath into /tmp) and the new ways maybe better, but I admit there was no clear consensus. I acted somewhat unilaterally. You know, I'm impatient and arrogant so... and Tinderbox is there to cause some restraint. There was definitely pushback on wanting unshipped binaries to keep working, which they largely do as a result of the discussion/pushback. As well, any unshipped binaries that we know we use in the build, like PklFonts, stubgen, m3bundle, we build standalone, to evade/avoid problems here, since $ORIGIN/../lib won't work and the full paths are meant to be omitted. I consider this not great. I think, really, we should be able to dynamically link everything really, including cm3. I don't think we should static link just to make up for the need for a backup. There are plenty of backups available and you can make plenty more. However this will have to wait and probably take more arguing and maybe demonstration of its viability. I will require some work to make work anyway. At one point I was confused about the need for static linking so accepted it strongly. Now I don't see it. If you just need backups, again, they exist, and you can make more. Static linking isn't imho a substitute for backups. There are technical problems to be solved though. Could be that these issues are related though. If your backup might load the wrong m3core.so too easily, making it not a very reliable backup, static linking could mitigate that. But $origin seems like a good mitigation. I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath. That way you can just put everything in one messy but easier to move/copy directory. - Jay > Date: Thu, 2 Jul 2009 20:04:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > Quoting Tony Hosking : > > > That sounds plausible. Is there anything in the current setup that > > depends on the .so files being in pkg instead of lib? > > I don't think so offhand. But I must admit that I've lost the overview > in this area, too :-/ > > Olaf > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > >> How about we put .so files only in lib and not in pkg? Or symlink > >> from pkg to lib instead of how it used to be the other way around? > >> Those would also fix all this. > >> > >> - Jay (phone) > >> > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> > >>> > >>> Are you up to date in m3-libs/m3core? > >>> Lots of builds have succeeded with this.. > >>> It isn't great, but that requirement to build from previous 5.4 release.. > >>> > >>> - Jay > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] ROOT > >>>> > >>>> If I define ROOT then I get the following error. I think this all > >>>> needs reverting! > >>>> > >>>> --- building in SOLgnu --- > >>>> > >>>> ignoring ../src/m3overrides > >>>> > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > >>>> 12: quake runtime error: unable to copy > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > >>>> "./UnixLink.c": errno=2 > >>>> > >>>> --procedure-- -line- -file--- > >>>> cp_if -- > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > >>>> > >>>> Fatal Error: package build failed > >>>> n > >>>> > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > >>>> > >>>> Where did variable ROOT come from? Do I really need to define it? > >>>> Seems broken to me to depend on the source directory structure > >>>> as it sets that structure in stone. > >>>> > >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:56:27 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:56:27 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: Here are some good links, other people trying to explain this stuff: http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the Avoiding LD_LIBRARY_PATH: The Options With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. LD_LIBRARY_PATH Seems Useful. What's the Problem? http://blogs.sun.com/rie/entry/hello_there Surfing With a Linker Alien http://blogs.sun.com/rie/entry/tt_ld_library_path_tt LD_LIBRARY_PATH - just say no A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: % ldd -s /usr/bin/date ... find object=libc.so.1; required by /usr/bin/date search path=/opt/ISV/lib (LD_LIBRARY_PATH) If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"` The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) (2004-07-10 22:20:54.0) Permalink Comments [8] Comments: .... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:13:14 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:13:14 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: http://linuxmafia.com/faq/Admin/ld-lib-path.html Why setting LD_LIBRARY_PATH is considered harmful For the following reasons: LD_LIBRARY_PATH is used in preference to any run time or default system linker path. If (God forbid) you had it set to something like /dcs/spod/baduser/lib, if there was a hacked version of libc in that directory (for example) your account could be compromised. It is for this reason that set-uid programs completely ignore LD_LIBRARY_PATH. When code is compiled and depends on this to work, it can cause confusion where different versions of a library are installed in different directories, for example there is a libtiff in /usr/openwin/lib and /usr/local/lib. In this case, the former library is an older one used by some programs that come with Solaris. Sometimes when using precompiled binaries they may have been built with 3rd party libraries in specific locations; ideally code should either ship with the libraries and install into a certain location or link the code as a pre-installation step. Solaris 7 introduces $ORIGIN which allows for a relative library location to be specified at run time (see the Solaris Linker and Libraries Guide). The alternative is to set LD_LIBRARY_PATH on a per-program basis, either as a wrapper program to the real program or a shell alias. Note however, that LD_LIBRARY_PATH may be inherited by programs called by the wrapped one ... http://lists.trolltech.com/qt4-preview-feedback/2005-04/msg00648.html Requiring LD_LIBRARY_PATH is not a good idea imo. It's a variable meant to override defaults, not for the common case. If all packages on ours disks would require this variable hell would break loose. Ask a system administrator. .... different person... Unfortunately rpath is not a solution by itself (although it could be part of the solution). Having rpath point to the build directory is a security hole. It can be part of the solution though ..yet another...shades of things I have said here... Now you may argue that runMyAppUsingQtAndMyLib needs to be re-linked deployment anyway. I agree that's what some programs do or should do (some have even suggested to distribute *.o files and relink them on the target platform using an adequate rpath, but that's a bad idea since the linker may be unpatched and the C++ compiler broken on the target platform). Some users won't relink though. Shouldn't Qt protect them by default? What do you think? http://lists.apple.com/archives/Unix-porting/2005/May/msg00034.html As others have pointed out there is not really an equivalent of LD_LIBRARY_PATH because the whole shared library system is unique to MacOS X/Darwin. I think it is fair to say that if you find yourself using DYLD_LIBRARY_PATH except for testing uninstalled binaries, then you are doing it wrong. Every executable file on Darwin contains the full paths of the libraries against which it was linked, and these are used first by dyld at runtime. They can be changed after linking. (see docs about install_name) So you should never need to specify some odd DYLD_LIBRARY_PATH with a properly installed library wherever it is installed. So now maybe I should search the web for negative comments about $origin? Well, when I try "what is wrong with ld $origin" I again find criticism of LD_LIBRARY_PATH. :) Ok, I admit I didn't look very hard. I'll look more later. So you see, the point is, there is a lot stuff out there discouraging LD_LIBRARY_PATH and encouraging full paths and/or $origin. Including Sun's linker developer(s). Full paths are ok for us, to the symlinks, if we then have full paths within the files. But if we use $origin, then the pkg store bites us. Is some of this making sense? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 18:56:27 +0000 Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Here are some good links, other people trying to explain this stuff: http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the Avoiding LD_LIBRARY_PATH: The Options With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. LD_LIBRARY_PATH Seems Useful. What's the Problem? http://blogs.sun.com/rie/entry/hello_there Surfing With a Linker Alien http://blogs.sun.com/rie/entry/tt_ld_library_path_tt LD_LIBRARY_PATH - just say no A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: % ldd -s /usr/bin/date ... find object=libc.so.1; required by /usr/bin/date search path=/opt/ISV/lib (LD_LIBRARY_PATH) If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"` The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) (2004-07-10 22:20:54.0) Permalink Comments [8] Comments: .... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:23:55 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: [M3devel] ROOT In-Reply-To: <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:30:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:30:22 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: Btw, I must say, that Modula-3 often bucks the trend, often with reason and benefit. However the "trend" has a lot of people behind it, using it, fixing it, making sure it works. The "trend", the popular practice, would include put the files in /usr/local/cm3/lib and not pkg. Or, well, pkg could be an unused copy, but that's fairly pointless and wasteful. My use of hardlinks is not exactly "trendy". But I was kinda sorta not breaking the "pkg philosophy". It's like the putting an extra unused copy in pkg, but without much space wastage (just directory entries) At least then the whole symlink/root thing can go away at least. Though just using a relative path to get the source file or copying and commiting a smaller piece of it, would be ok..if someone wants hardlink primitive in cm3 for some reason still. The runpath won't be huge then also, no matter how all the other debating goes. I need some time to settle down and think about it and /try it out/ but at the moment I'm tempted by the ditching of pkg for .so files and just them in lib. It will require probably new builder and config file changes. Really the current hardlink solution is extremely close to this, but again, also not "trendy". .a/.sa files would remain where they are, in pkg, though, of course, there is "very trendy" precedent against that too. And then, er...what is left in pkg? - Jay From: jay.krell at cornell.edu To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: Re: [M3devel] ROOT >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:37:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:37:45 -0400 Subject: [M3devel] ROOT In-Reply-To: <4A4CC4CE.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I think best would be for Jay to reprise his thinking on why all of this was needed. In general, I oppose hard links on the grounds that they are not trivially migrateable. Better to have relative symbolic links. If we can avoid the need for $origin by installing libraries in a fixed INSTALL_ROOT/lib directory (rather than the current symbolic links approach) then I prefer that. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 14:31, Randy Coleburn wrote: > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:47:23 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:47:23 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I half agree. It'll be a few hours/days, maybe a week, but I'll take a stab at only putting the files in lib. I don't know if it'll be easy or not but I'll try. Therefore no hardlinks. But still $origin. Unless maybe there is consensus that install must be /usr/local/cm3, unless you build/link yourself, then you can chose. And the distribution building will have to be sure to...um...? Be done as root and impact the running system??? No.. Well, distribution building can make it work somehow, by using -rpath /usr/local/cm3/lib, even if ld is pointed at /tmp/cm3/lib/libfoo.so. I can look into that, if there is actually firm consensus against $origin and for full paths, and for taking away user choice of install location...but...but....what about non-admin installs? They have to rebuild? As a non-admin installer on cm3, I can probably live with that, but not sure about others..seems not great. Another option is to link upon install, or "fixup" the paths on systems that can do that without relinking. Again I come back to favoring origin pretty strongly. Hard links seem perfectly migratable..they tar and untar at least.. I get it probably though -- what flags to use to cp? There are too many options, it confuses me. I know hard links can't cross file systems, but often people only hardlink "nearby" files that are the same file system anyway. Hardlinks don't survive on Windows FAT filesystem, probably nobody cares. They work fine on NTFS. Some copy utilities might break them though, yeah, that happens. Full paths not using $origin aren't migratable. - Jay From: hosking at cs.purdue.edu To: rcolebur at scires.com Date: Thu, 2 Jul 2009 15:37:45 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT I think best would be for Jay to reprise his thinking on why all of this was needed. In general, I oppose hard links on the grounds that they are not trivially migrateable. Better to have relative symbolic links. If we can avoid the need for $origin by installing libraries in a fixed INSTALL_ROOT/lib directory (rather than the current symbolic links approach) then I prefer that. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 14:31, Randy Coleburn wrote: I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:48:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:48:14 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> On 2 Jul 2009, at 14:41, Jay wrote: > Before I explain, more options: > > copy and commit the source to cm3 is viable I don't know what this sentence means. > heck, use a relative instead of absolute from ROOT ditto > go back to the old way (I'll explain) I think I understand the shortcomings here but Jay should explain. > There is also the option to relink or "fixup" > upon ship and/or install. Some platforms have a "fixup" > utility for exactly "these reasons". > MacOS X has one. Sounds feasible, but I worry about portability of this approach. > The question is: > > How does program foo find libbar.so? > At runtime. Right. rpaths in the executable should do the trick. > How does libbar.so find libfoo.so? Same again. > There are a bewildering array of choices. > They are combinable. > It varies somewhat from platform by platform, but not much really. Ideally we use the same approach for *all* platforms. So, what do all platforms have in common. > The main options are: > > > 1: A full path written into program foo > or libbar pointing to e.g. /usr/lib/libfoo.so. > Actually this is usually separate libfoo.so and > a list of directories that apply to all .so files. > There isn't generally a matching up of directory to file, > I think, but a "search path" aka "run path". i.e., rpath? > 2: A relative path written into program foo > or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. > Again, the directories are split from the files. Please explain the implications of this w.r. to hard links! I don't want hard links. > MacOS X doesn't have $ORIGIN by that name, but it > has three similar things, like @executable_path. > @executable_path goes way back and is presumably > relative to the primary main executable. Then we should avoid $ORIGIN. Use the linker options to specify rpaths (and if there is need for override use $LD_LIBRARY_PATH. > There are two other similar options. > One is new in 10.5. Presumably one is relative > to the reference. And maybe one is some concatenation > of all directories anything found in so far? I don't know. > The documenation was not clear to me. Again, I'd like to use the same approach on all platforms (except perhaps Windows). > NetBSD prior to 5.0 doesn't have $ORIGIN. A good reason not to use it. > NT searches $PATH always. > We put the .dlls in bin. > Cygwin same. OK, so things work fine there. > Approximately all other systems seem to support about the same > $ORIGIN feature: > OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and > others (Aix? Irix? HP-UX?) > The MacOS X feature is close enough to lump in. > > 3: Search $LD_LIBRARY_PATH or similar. > This has a few different names. > LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. These are fallbacks for the situation when the default installed configuration needs overriding. > Now, our historical implementation was > - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, > a path for every dependency > The file formats are generally such that there are leaf file names > separate from an array of directories to look in. A "normal" > non-Modula-3 program would generally I assume have a prety small > such array of directories. A "normal" Modula-3 program would have > a fairly large array. But if everything goes in INSTALL_ROOT/lib we have only one directory, right? > As well, doing builds for distribution would often leave you with / > tmp/cm3 > which is a possible security problem. This definitely did occur. Surely, building for a distro can build in the right path. Where did / tmp/cm3 come from? If you need to be able to override while building then use $LD_LIBRARY_PATH. > Now, again, there are many options, and they can be combined. > Portability is perhaps a concern, but perhaps not so much, given > today's landscape. Elegance is also a concern. > Now, if we are to use relative paths, well, my understanding is that > the "real" files need to be in relatively few directories, e.g. /usr/ > local/cm3/lib, > and not /usr/local/cm3/pkg/foo/linux etc. I prefer this approach. > This way, files in lib and bin can point to $ORIGIN/../lib. Fair enough. > Now, keep in mind, that unshipped binaries sometimes people like to > work, > as well, perhaps also programs (not shared libraies, as far as I know) > buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. > I know cm3 sits in there, though that copy isn't used. I don't know understand what you are trying to say here. > I make no account for binaries buried in the package store. > > I do make some account for unshipped binaries. > > By default the run paths we are recording in current config files > are > $ORIGIN/../lib:/usr/local/cm3/lib > Not a bunch of paths into pkg, just two entries. > > > The "security" issue still is present by default. > But the run path is "prettier" and probably more efficient. > > > When you build a distribution however, you are expected to omit /usr/ > local/cm3/lib (it might be /tmp/cm3). > This is controled by an environment variable, which I set in Olaf's > scripts, but oops > I think I set it too late. I'll fix that very very soon. The following is a bit rambling for me to respond to in detail. Perhaps someone else should weigh in. > > > To recap: > - full paths > - relative paths from $ORIGIN > - LD_LIBRARY_PATH > > They each have advantages and disadvantages. > $ORIGIN provides for a "movable" install. I can install to /usr/ > local/cm3, > you can install to /opt/cm3. It'll just work. No need to change > LD_LIBRARY_PATH. > > > However if I want to move just some of the files, not the whole > binary tree > together, then $ORIGIN breaks down. > > > If really want one file here, another there, and another somewhere > else, $ORIGIN doesn't do. > You are left with full paths or LD_LIBRARY_PATH. > > > Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or > such. > Look on birch for example, it is /usr/local/cm3/lib. > That tripped me up actually, because, you know, my cm3 is in $HOME/ > cm3 there. > This demonstrated another problem in this area! > $ORIGIN keeps things more tightly together, which you often want, > sometimes might not not. > LD_LIBRARY_PATH lets things be spread around, again, sometimes you > want that, sometimes not. > I figure tightly point is the more common, but imagine if you just > want to replace one file. > Is that reasonable? You replace it by putting it elsewhere? > (Imagine "patching" an install > this way.) > > > So, here now I'm rambling. > I've laid out the options and /some/ of the disadvantages/advantages. > > > There is no perfect solution, and the various solutions are > combinable. > I find combining them though, I start to get confused. > Because you end up in a "probing" situation and you start wondering > which supercedes which, and you just hope there aren't any > "duplicates" > so that the probe order is mostly moot (assuming there remain no > duplicates). > > > Somewhat clear? > > > You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo > or ldd -v or -V foo and > investigate the various options and their effects. Solaris has a > very nice and verbose > ldd form. > > > Now, the files in pkg. > I consider it somewhat philosophically significant that "everything > is in pkg". > There is a well structured "repository" not a randomly organized > bunch of files. > I think. Maybe this is just a suggestion? > You know, if they are hardlinks and we don't really use the ones in > pkg, is > there a point? > > > Or, on the other hand, is the philosophy a big deal and we should go > back to > lib symlinking to pkg to appease the philosophy? > > > "ship/install" certainly "likes" to put things in pkg. > I don't think the option of using lib and not pkg is doable without > builder changes. > But that is doable. > > > A few other folks here did pipe up some on this in the recent past and > I think there was kinda sorta consensus that the old ways were not > great > (particularly 1) the big runpath 2) the runpath into /tmp) > and the new ways maybe better, but I admit there was no clear > consensus. > I acted somewhat unilaterally. You know, I'm impatient and arrogant > so... > and Tinderbox is there to cause some restraint. > > > There was definitely pushback on wanting unshipped binaries to keep > working, > which they largely do as a result of the discussion/pushback. > > > As well, any unshipped binaries that we know we use in the build, > like PklFonts, > stubgen, m3bundle, we build standalone, to evade/avoid problems here, > since $ORIGIN/../lib won't work and the full paths are meant to be > omitted. > I consider this not great. > > I think, really, we should be able to dynamically link everything > really, > including cm3. I don't think we should static link just to make up for > the need for a backup. There are plenty of backups available and you > can > make plenty more. However this will have to wait and probably take > more arguing and maybe demonstration of its viability. > I will require some work to make work anyway. > > > At one point I was confused about the need for static linking so > accepted it strongly. > Now I don't see it. If you just need backups, again, they exist, and > you can make more. > Static linking isn't imho a substitute for backups. > There are technical problems to be solved though. > > Could be that these issues are related though. If your backup might > load the wrong m3core.so too easily, making it not a very reliable > backup, > static linking could mitigate that. But $origin seems like a good > mitigation. > I'm strongly considering add just plain $origin, in addition to > $origin/../lib to runpath. > That way you can just put everything in one messy but easier to move/ > copy directory. > > > - Jay > > > > > > > Date: Thu, 2 Jul 2009 20:04:36 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] ROOT > > > > Quoting Tony Hosking : > > > > > That sounds plausible. Is there anything in the current setup that > > > depends on the .so files being in pkg instead of lib? > > > > I don't think so offhand. But I must admit that I've lost the > overview > > in this area, too :-/ > > > > Olaf > > > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > > > >> How about we put .so files only in lib and not in pkg? Or symlink > > >> from pkg to lib instead of how it used to be the other way > around? > > >> Those would also fix all this. > > >> > > >> - Jay (phone) > > >> > > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > > >> > > >>> > > >>> Are you up to date in m3-libs/m3core? > > >>> Lots of builds have succeeded with this.. > > >>> It isn't great, but that requirement to build from previous > 5.4 release.. > > >>> > > >>> - Jay > > >>> > > >>> ________________________________ > > >>>> From: hosking at cs.purdue.edu > > >>>> To: hosking at cs.purdue.edu > > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] ROOT > > >>>> > > >>>> If I define ROOT then I get the following error. I think this > all > > >>>> needs reverting! > > >>>> > > >>>> --- building in SOLgnu --- > > >>>> > > >>>> ignoring ../src/m3overrides > > >>>> > > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > > >>>> 12: quake runtime error: unable to copy > > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > > >>>> "./UnixLink.c": errno=2 > > >>>> > > >>>> --procedure-- -line- -file--- > > >>>> cp_if -- > > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ > m3makefile > > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > > >>>> > > >>>> Fatal Error: package build failed > > >>>> n > > >>>> > > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > > >>>> > > >>>> Where did variable ROOT come from? Do I really need to define > it? > > >>>> Seems broken to me to depend on the source directory structure > > >>>> as it sets that structure in stone. > > >>>> > > >>>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:52:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:52:38 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: <86309DFE-9D46-4092-AE9D-B94BA88234E8@cs.purdue.edu> On 2 Jul 2009, at 14:48, Jay wrote: > Hopefully my other mail will help clear this up. Jay, it's generally best to confine yourself to one e-mail instead of multiple. My (mental) bandwidth is saturated by the number of e-mails I must read in a day, so I can't keep track of all of yours. > I'd also like to do other Modula-3 work: > 64 bit file sizes on all platforms > I'm at least going to try. This might cascade too far and break > a lot of things, since INTEGER and LONGINT cannot be freely > intermixed, you can't even assign an INTEGER to a LONGINT! You can convert an INTEGER to a LONGINT. It is deliberate that INTEGER and LONGINT be unrelated types, in keeping with the spirit of M3. Implicit C casts are notorious sources of bugs. > Merge gcc-interix with gcc. It turns out this is quite small. > > Enable the "portable runpaths" in Olaf's scripts (related to all > this). > I put the lines in slightly too far down in the code, oops. Olaf, can you help clarify? > > > > - Jay > > Date: Thu, 2 Jul 2009 14:31:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:59:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:59:25 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:59:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:59:50 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> Message-ID: > copy and commit the source to cm3 is viable > I don't know what this sentence means. I don't have to be copying files around in the build order for cm3 to create hard links. I can just copy on my machine and commit to cvs a little bit of code to do it. That isn't nearly as hacky. > heck, use a relative instead of absolute from ROOT > ditto $origin it turns out is very portable. Every system we support except NetBSD 4.0 seems to have it, and even some we don't currently support. And NetBSD 5.0, which already released, has it. And MacOSX is plenty close enough. It is a matter of relative to the executable or the reference, and which OS version you support. I believe newer versions relaly do have $origin by another name, but 10.4 has relative to the executable, which is good enough to me. If you don't use $origin, then people either must install to the one true place, or they must use LD_LIBRARY_PATH, or they must rebuild/relink/fixup themselves. LD_LIBRARY_PATH is widely panned. Having to rebuild seems onerous for most people. Having a choice of where to install? Important? > Right. rpaths in the executable should do the trick. Just in the executable? Shouldn't they somewhat be in the shared libraries? If foo uses libm3 and libm3 uses m3core and foo doesn't use m3core, arguably foo shouldn't mention m3core, only libm3 should. > Ideally we use the same approach for *all* platforms. So, what do all platforms have in common. $origin comes extremely close to that, and provides the benefit that user can specify where to install. > and if there is need for override use $LD_LIBRARY_PATH. But again (I know, I repeated myself, so you did, now I am), this forces any install to non-default location to use LD_LIBRARY_PATH. It is an option. But $origin is also /very/ portable... >> But if everything goes in INSTALL_ROOT/lib we have only one directory, right? Correct. That is what I achieved with the hardlinks, and will try to achieve shortly without them. > Surely, building for a distro can build in the right path. Not really. It would disrupt the running multiuser system. But it can probably use -rpath to stick paths in that don't correspond to the "staging" area. > Where did /tmp/cm3 come from? The distribution builds in /tmp. You don't have to be root or disrupt the running machine to build a distribution. There a question maybe of if the resulting files should be owned by root? > Elegance is also a concern. Agreed. Copying files in the build isn't elegant. The result is elegant imho. Hardlinks aren't elegant? I don't know. Anyway, ok, I'll just put the files in lib and no hardlinks, I'll try that. > Now, keep in mind, that unshipped binaries sometimes people like to work > I don't know understand what you are trying to say here. Let me think about unshipped binaries later.. One thing is that $origin doesn't work with unshipped binaries. By default we put in both $origin and the full path you like. But imho distributions should just have $origin. Or if user can't chose install location, maybe just the full path. The big question is if user can chose where to install. On birch I use $HOME/cm3. Seems kind of important/useful? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:02:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:02:56 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: Yes, now I remember. We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core. This implies the need for compilations upstream of m3core to function with both old and new versions. So, my question now is why did you introduce a dependency from the new cm3 to the new m3core? That should probably be avoided. On 2 Jul 2009, at 15:23, Jay wrote: > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:03:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:03:16 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> Message-ID: Ok, so I think a very important question is: >>> Should users have a choice of where to install? >>> What are the reasonable ramifications of someone who makes a non-default choice? /Personally/ I want the choice, esp. if I don't have root access!, and I don't want to set LD_LIBRARY_PATH. I want my choice and no negative consequences, and $origin basically gives me that. Except NetBSD prior to 5.0. 5.0 already released. And I guess Solaris prior to 2.7 or such. We do agree on a change vs. previous releases, at least. And it overlaps with what I did already. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 15:59:25 -0400 I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:05:25 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:05:25 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > why did you introduce a dependency to the new m3core I had removed link because it wasn't used, and/or didn't introduce it the first builds of e.g. AMD64_LINUX. Link naturally goes in m3core/src/unix. However implementing it locally in cm3 is reasonable. I should have tried harder on a clean local unshared solution. Not every .c file needs m3unix.h, though I am comforted by using it, that I have things all setup well and portably. Waitpid changes similar, you'll recall. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 16:02:56 -0400 Yes, now I remember. We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core. This implies the need for compilations upstream of m3core to function with both old and new versions. So, my question now is why did you introduce a dependency from the new cm3 to the new m3core? That should probably be avoided. On 2 Jul 2009, at 15:23, Jay wrote: >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:08:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:08:26 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: On 2 Jul 2009, at 15:30, Jay wrote: > Btw, I must say, that Modula-3 often bucks the trend, often with > reason and benefit. > However the "trend" has a lot of people behind it, using it, fixing > it, making sure it works. > The "trend", the popular practice, would include put the files in / > usr/local/cm3/lib and not pkg. I am fine with this. > Or, well, pkg could be an unused copy, but that's fairly pointless > and wasteful. I don't know what the reasons were for putting them in the pkg directories in the first place. > My use of hardlinks is not exactly "trendy". > But I was kinda sorta not breaking the "pkg philosophy". Does anyone recall if there was any real "philosophy" here? > It's like the putting an extra unused copy in pkg, but without much > space wastage (just directory entries) > > At least then the whole symlink/root thing can go away at least. > Though just using a relative path to get the source file or copying > and commiting a smaller piece of it, would be ok..if someone wants > hardlink primitive in cm3 for some reason still. I oppose hard links in general. > The runpath won't be huge then also, no matter how all the other > debating goes. > > > I need some time to settle down and think about it and /try it out/ > but at the moment I'm tempted by the ditching of pkg for .so files > and just them in lib. It will require probably new builder and > config file changes. RIght. > Really the current hardlink solution is extremely close to this, but > again, also not "trendy". > .a/.sa files would remain where they are, in pkg, though, of course, > there is "very trendy" precedent against that too. I suspect that the "pkg" philosophy dates from before .so shared libraries were even supported on most targets (yes, I can remember that long ago). > And then, er...what is left in pkg? Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). > > - Jay > > From: jay.krell at cornell.edu > To: jay.krell at cornell.edu; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 19:23:55 +0000 > Subject: Re: [M3devel] ROOT > > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:17:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:17:54 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> Message-ID: <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> On 2 Jul 2009, at 16:03, Jay wrote: > Ok, so I think a very important question is: > > >>> Should users have a choice of where to install? Yes! > >>> What are the reasonable ramifications of someone who makes a > non-default choice? > > /Personally/ I want the choice, esp. if I don't have root access!, > and I don't want to set LD_LIBRARY_PATH. > I want my choice and no negative consequences, and $origin basically > gives me that. > Except NetBSD prior to 5.0. 5.0 already released. > And I guess Solaris prior to 2.7 or such. > > > We do agree on a change vs. previous releases, at least. > And it overlaps with what I did already. I think so. (I just didn't like the link stuff and I still don't understand what ROOT is there for). > > > - Jay > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 15:59:25 -0400 > > I agree, LD_LIBRARY_PATH should only be used by power-users in a > pinch during development. > > On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:19:41 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:19:41 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > And then, er...what is left in pkg? Sorry, that was an unfinished thought. Various other things left, none of them will move. You might argue to move .sa files, but doesn't really matter, leave it alone, unless it is super duper convenient to move them along with the .so. It might be, because of how build_standalone works, or maybe only out of laziness. Except .so.5 along with .so. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 2 Jul 2009 16:08:26 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT On 2 Jul 2009, at 15:30, Jay wrote: Btw, I must say, that Modula-3 often bucks the trend, often with reason and benefit. However the "trend" has a lot of people behind it, using it, fixing it, making sure it works. The "trend", the popular practice, would include put the files in /usr/local/cm3/lib and not pkg. I am fine with this. Or, well, pkg could be an unused copy, but that's fairly pointless and wasteful. I don't know what the reasons were for putting them in the pkg directories in the first place. My use of hardlinks is not exactly "trendy". But I was kinda sorta not breaking the "pkg philosophy". Does anyone recall if there was any real "philosophy" here? It's like the putting an extra unused copy in pkg, but without much space wastage (just directory entries) At least then the whole symlink/root thing can go away at least. Though just using a relative path to get the source file or copying and commiting a smaller piece of it, would be ok..if someone wants hardlink primitive in cm3 for some reason still. I oppose hard links in general. The runpath won't be huge then also, no matter how all the other debating goes. I need some time to settle down and think about it and /try it out/ but at the moment I'm tempted by the ditching of pkg for .so files and just them in lib. It will require probably new builder and config file changes. RIght. Really the current hardlink solution is extremely close to this, but again, also not "trendy". .a/.sa files would remain where they are, in pkg, though, of course, there is "very trendy" precedent against that too. I suspect that the "pkg" philosophy dates from before .so shared libraries were even supported on most targets (yes, I can remember that long ago). And then, er...what is left in pkg? Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). - Jay From: jay.krell at cornell.edu To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: Re: [M3devel] ROOT >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:23:35 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:23:35 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> Message-ID: (I just didn't like the link stuff and I still don't understand what ROOT is there for). The point was to add Unix.link where it belongs, m3core, and use it from where can't depend on new m3core. And maybe go overboard in sharing the source, to a trivial one line function (less trivial on Win32, in order to support pre-Win2000 OS). The point was to put the files in lib and also leave them in pkg, without wasting space. The decision now, which I still have to try, is to stop putting the files in pkg, so then no hardlink needed. $origin vs. full paths is still debatable and I still convinced $origin is the way to go. I'm also inclined to put $origin and $origin/../lib in rpath, so backups can flatten the structure to just one directory: /backup/cm3 /backup/libm3core.so /backup/libm3.so in some /hypothetical future/ where cm3 is dynamically linked. As long there are no "duplicates" -- files in both bin and lib, the runpath remains fairly clear/unambiguous. And even then, the order is pretty clearly left to right.. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 16:17:54 -0400 On 2 Jul 2009, at 16:03, Jay wrote: Ok, so I think a very important question is: >>> Should users have a choice of where to install? Yes! >>> What are the reasonable ramifications of someone who makes a non-default choice? /Personally/ I want the choice, esp. if I don't have root access!, and I don't want to set LD_LIBRARY_PATH. I want my choice and no negative consequences, and $origin basically gives me that. Except NetBSD prior to 5.0. 5.0 already released. And I guess Solaris prior to 2.7 or such. We do agree on a change vs. previous releases, at least. And it overlaps with what I did already. I think so. (I just didn't like the link stuff and I still don't understand what ROOT is there for). - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 15:59:25 -0400 I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:24:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:24:08 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> On 2 Jul 2009, at 15:47, Jay wrote: > I half agree. ;-) > It'll be a few hours/days, maybe a week, but I'll take a stab at > only putting the files in lib. > I don't know if it'll be easy or not but I'll try. > Therefore no hardlinks. Cool! > But still $origin. I think so, but still not sure. > Unless maybe there is consensus that install must be /usr/local/ > cm3, unless you build/link yourself, then you can chose. My inclination is that a binary install (no build/link) is OK to be hardwired, but if $origin gives flexibility in that then perhaps worth supporting. But surely, for binary installs we will be using package managers to install to standard places so no need to adjust the paths? > And the distribution building will have to be sure to...um...? Be > done as root and impact the running system??? No.. > Well, distribution building can make it work somehow, by using - > rpath /usr/local/cm3/lib, even if ld is pointed at /tmp/cm3/lib/ > libfoo.so. I can look into that, if there is actually firm consensus > against $origin and for full paths, and for taking away user choice > of install location...but...but....what about non-admin installs? > They have to rebuild? As a non-admin installer on cm3, I can > probably live with that, but not sure about others..seems not great. > Another option is to link upon install, or "fixup" the paths on > systems that can do that without relinking. > Again I come back to favoring origin pretty strongly. OK, now I think I understand where you are coming from. You want binary installs (no build/link) for non-admin users to non-standard places. Seems like a desirable thing in theory. > Hard links seem perfectly migratable..they tar and untar at least.. > I get it probably though -- what flags to use to cp? There are too > many options, it confuses me. > I know hard links can't cross file systems, but often people only > hardlink "nearby" files that are the same file system anyway. > Hardlinks don't survive on Windows FAT filesystem, probably nobody > cares. They work fine on NTFS. > Some copy utilities might break them though, yeah, that happens. I generally avoid them because of the swamp you just described. > Full paths not using $origin aren't migratable. Right. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcolebur at scires.com > Date: Thu, 2 Jul 2009 15:37:45 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > I think best would be for Jay to reprise his thinking on why all of > this was needed. In general, I oppose hard links on the grounds > that they are not trivially migrateable. Better to have relative > symbolic links. If we can avoid the need for $origin by installing > libraries in a fixed INSTALL_ROOT/lib directory (rather than the > current symbolic links approach) then I prefer that. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 14:31, Randy Coleburn wrote: > > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:24:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:24:38 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > I oppose hard links in general. Why? This is hypothetical/just-curious now, because we have agreed to take away the need I had for them. But then when I think I want them tomorrow again, what is the reason not? :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:25:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:25:03 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: <6FB1A21F-E26D-435D-AEE2-1C2337E92C09@cs.purdue.edu> On 2 Jul 2009, at 16:19, Jay wrote: > > And then, er...what is left in pkg? > > > Sorry, that was an unfinished thought. > Various other things left, none of them will move. > You might argue to move .sa files, but doesn't really matter, leave > it alone, unless it is super duper convenient to move them along > with the .so. It might be, because of how build_standalone works, or > maybe only out of laziness. > Except .so.5 along with .so. RIght. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 2 Jul 2009 16:08:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > On 2 Jul 2009, at 15:30, Jay wrote: > > Btw, I must say, that Modula-3 often bucks the trend, often with > reason and benefit. > However the "trend" has a lot of people behind it, using it, fixing > it, making sure it works. > The "trend", the popular practice, would include put the files in / > usr/local/cm3/lib and not pkg. > > I am fine with this. > > Or, well, pkg could be an unused copy, but that's fairly pointless > and wasteful. > > I don't know what the reasons were for putting them in the pkg > directories in the first place. > > My use of hardlinks is not exactly "trendy". > But I was kinda sorta not breaking the "pkg philosophy". > > Does anyone recall if there was any real "philosophy" here? > > It's like the putting an extra unused copy in pkg, but without much > space wastage (just directory entries) > > At least then the whole symlink/root thing can go away at least. > Though just using a relative path to get the source file or copying > and commiting a smaller piece of it, would be ok..if someone wants > hardlink primitive in cm3 for some reason still. > > I oppose hard links in general. > > The runpath won't be huge then also, no matter how all the other > debating goes. > > > I need some time to settle down and think about it and /try it out/ > but at the moment I'm tempted by the ditching of pkg for .so files > and just them in lib. It will require probably new builder and > config file changes. > > RIght. > > Really the current hardlink solution is extremely close to this, but > again, also not "trendy". > .a/.sa files would remain where they are, in pkg, though, of course, > there is "very trendy" precedent against that too. > > I suspect that the "pkg" philosophy dates from before .so shared > libraries were even supported on most targets (yes, I can remember > that long ago). > > And then, er...what is left in pkg? > > Sources. For browsing by the various Modula-3 tools. Come to think > of it, that reminds me -- the package browsing tools (eg, m3browser) > rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, > this argues for only moving the .so files to INSTALL_ROOT/lib and > leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived > sources in the pkg/TARGET directories where they currently reside). > > > - Jay > > From: jay.krell at cornell.edu > To: jay.krell at cornell.edu; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 19:23:55 +0000 > Subject: Re: [M3devel] ROOT > > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:26:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:26:38 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> Message-ID: <51053E7F-533F-4951-9E13-62122B2BB983@cs.purdue.edu> I think we are converging on a reasonable compromise (as noted in my other responses). On 2 Jul 2009, at 15:59, Jay wrote: > > copy and commit the source to cm3 is viable > > I don't know what this sentence means. > > I don't have to be copying files around in the build order for cm3 > to create hard links. > I can just copy on my machine and commit to cvs a little bit of code > to do it. > That isn't nearly as hacky. > > > heck, use a relative instead of absolute from ROOT > > ditto > > > $origin it turns out is very portable. > Every system we support except NetBSD 4.0 seems to have it, and > even some we don't currently support. > And NetBSD 5.0, which already released, has it. > And MacOSX is plenty close enough. It is a matter of relative to > the executable or the reference, and which OS version you support. I > believe newer versions relaly do have $origin by another name, but > 10.4 has relative to the executable, which is good enough to me. > > If you don't use $origin, then people either must install to the one > true place, or they must use LD_LIBRARY_PATH, or they must rebuild/ > relink/fixup themselves. > > LD_LIBRARY_PATH is widely panned. > Having to rebuild seems onerous for most people. > Having a choice of where to install? Important? > > > > Right. rpaths in the executable should do the trick. > > Just in the executable? Shouldn't they somewhat be in the shared > libraries? > If foo uses libm3 and libm3 uses m3core and foo doesn't use m3core, > arguably foo shouldn't mention m3core, only libm3 should. > > > > Ideally we use the same approach for *all* platforms. So, what > do all platforms have in common. > > $origin comes extremely close to that, and provides the benefit that > user can specify where to install. > > > > and if there is need for override use $LD_LIBRARY_PATH. > > But again (I know, I repeated myself, so you did, now I am), this > forces any install to non-default location to use LD_LIBRARY_PATH. > It is an option. But $origin is also /very/ portable... > > >> But if everything goes in INSTALL_ROOT/lib we have only one > directory, right? > > Correct. That is what I achieved with the hardlinks, and will try to > achieve shortly without them. > > > Surely, building for a distro can build in the right path. > > Not really. It would disrupt the running multiuser system. > But it can probably use -rpath to stick paths in that don't > correspond to the "staging" area. > > > > Where did /tmp/cm3 come from? > > The distribution builds in /tmp. You don't have to be root or > disrupt the running machine to build a distribution. > There a question maybe of if the resulting files should be owned by > root? > > > > Elegance is also a concern. > > Agreed. Copying files in the build isn't elegant. The result is > elegant imho. > Hardlinks aren't elegant? I don't know. > Anyway, ok, I'll just put the files in lib and no hardlinks, I'll > try that. > > Now, keep in mind, that unshipped binaries sometimes people like > to work > > I don't know understand what you are trying to say here. > > Let me think about unshipped binaries later.. > One thing is that $origin doesn't work with unshipped binaries. > By default we put in both $origin and the full path you like. > But imho distributions should just have $origin. > Or if user can't chose install location, maybe just the full path. > The big question is if user can chose where to install. > On birch I use $HOME/cm3. > Seems kind of important/useful? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:30:47 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:30:47 +0000 Subject: [M3devel] ROOT In-Reply-To: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: > But surely, for binary installs we will be using package managers to install to standard places so no need to adjust the paths? Yes and no. In fact, yes, I made some .deb files, and they have no choice of where to install. They have no "install code", beyond dpkg. But .deb files often do have install scripts in them. It's not a hard requirement to avoid. And the normal workflow with apt-get install doesn't give you a choice of install location either. Historically we don't have little/no use of package manages. Therefore open the other can of worms of what a binary install should look like... (Echoing Olaf here) There are way too many install formats, while it is nice for us to support some of them, it behooves us to have our own low end portable form, and we have some say in the feature set of it, such as if you can chose the install location. (We could also adopt one of the native ones as our portable one, if it is in fact portable; .deb it turns out is actually promising in this regard, it takes like two lines of .sh to install a .deb on pretty much any system, assuming the contents are for it; they are just a .tar.gz bundled with very little else in an ar file.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 19:34:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 10:34:55 -0700 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> How about we put .so files only in lib and not in pkg? Or symlink from pkg to lib instead of how it used to be the other way around? Those would also fix all this. - Jay (phone) On Jul 2, 2009, at 9:21 AM, Jay wrote: > > Are you up to date in m3-libs/m3core? > Lots of builds have succeeded with this.. > It isn't great, but that requirement to build from previous 5.4 > release.. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 2 Jul 2009 11:54:51 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ROOT >> >> If I define ROOT then I get the following error. I think this all >> needs reverting! >> >> --- building in SOLgnu --- >> >> ignoring ../src/m3overrides >> >> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: >> quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ >> Common/UnixLink.c" to "./UnixLink.c": errno=2 >> >> --procedure-- -line- -file--- >> cp_if -- >> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >> m3makefile >> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >> >> Fatal Error: package build failed >> n >> >> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as >> it sets that structure in stone. >> >> From jay.krell at cornell.edu Thu Jul 2 22:35:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:35:20 +0000 Subject: [M3devel] ROOT In-Reply-To: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: > You want binary installs (no build/link) for non-admin users to non-standard places Right, and without having to set LD_LIBRARY_PATH (except on NetBSD 4.0 :) ) "What is the cost of a non-default install location?" - Jay From: hosking at cs.purdue.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:39:13 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:39:13 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: In the meantime btw, I assert things are broken. Consider putting it all back as it was. Tonight I can try using a relative path instead of ROOT, as a baby step. Or I can commit the code so that build doesn't copy it. Or we can have cm3 depend on m3core and leave "release" broken for a bit. As I said, I wouldn't mind relaxing that requirement (I suspect Olaf disagrees strongly though.) Or you can finish the reversion by lookin for "hardlink" in the config files and changing it to just "link". That might work. Might. Really, more so, look for the uses of $origin and remove them too. I really need to run catch a plain and spend time with family though. Later, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 23:02:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 14:02:48 -0700 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: I can put if back tonight and then remove 'root' and then hardlinks will remain temporarily. - Jay (phone) On Jul 2, 2009, at 1:39 PM, Jay wrote: > In the meantime btw, I assert things are broken. > > Consider putting it all back as it was. > > Tonight I can try using a relative path instead of ROOT, as a baby > step. > Or I can commit the code so that build doesn't copy it. > > Or we can have cm3 depend on m3core and leave "release" broken for a > bit. > As I said, I wouldn't mind relaxing that requirement (I suspect Olaf > disagrees strongly though.) > > Or you can finish the reversion by lookin for "hardlink" in the > config files and changing it to just "link". > That might work. Might. > Really, more so, look for the uses of $origin and remove them too. > > > I really need to run catch a plain and spend time with family though. > > > Later, > - Jay From jay.krell at cornell.edu Thu Jul 2 23:04:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 14:04:40 -0700 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: (and keep it compatible with old cm3) - Jay (phone) On Jul 2, 2009, at 2:02 PM, jayk123 at hotmail.com wrote: > I can put if back tonight and then remove 'root' and then hardlinks > will remain temporarily. > > - Jay (phone) > > On Jul 2, 2009, at 1:39 PM, Jay wrote: > >> In the meantime btw, I assert things are broken. >> >> Consider putting it all back as it was. >> >> Tonight I can try using a relative path instead of ROOT, as a baby >> step. >> Or I can commit the code so that build doesn't copy it. >> >> Or we can have cm3 depend on m3core and leave "release" broken for >> a bit. >> As I said, I wouldn't mind relaxing that requirement (I suspect >> Olaf disagrees strongly though.) >> >> Or you can finish the reversion by lookin for "hardlink" in the >> config files and changing it to just "link". >> That might work. Might. >> Really, more so, look for the uses of $origin and remove them too. >> >> >> I really need to run catch a plain and spend time with family though. >> >> >> Later, >> - Jay From rcolebur at scires.com Thu Jul 2 23:54:51 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 17:54:51 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: <4A4CF46A.1E75.00D7.1@scires.com> Also, let us not forget about CM3IDE (formerly Reactor). It can browse multiple repositories, some marked public and some marked private. We don't want to introduce changes in the way stuff is shipped that would break CM3IDE or M3BROWSER. I think the browsing capabilities in CM3IDE are an outgrowth of the old m3browser and expand upon it to show dependencies, lists of interfaces/implementions imported/exported, etc. etc. CM3IDE also relies on knowledge of the cm3 file tree to locate stuff and to create new packages, etc. If we muck around too much with all of this, we risk breaking CM3IDE or at least having to adapt it to whatever new structure/rules are in place. Regards, Randy Coleburn >>> Tony Hosking 7/2/2009 4:08 PM >>> Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jul 3 00:19:15 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 15:19:15 -0700 Subject: [M3devel] ROOT In-Reply-To: <4A4CF46A.1E75.00D7.1@scires.com> References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> <4A4CF46A.1E75.00D7.1@scires.com> Message-ID: <56A22159-9AB8-4A47-B5BF-3812A45051B4@hotmail.com> Ok. I doubt IDE cares about this and we can make symlinks on most platforms. We will not move .m3web .m3exports .m3x etc. - Jay (phone) On Jul 2, 2009, at 2:54 PM, "Randy Coleburn" wrote: > Also, let us not forget about CM3IDE (formerly Reactor). It can > browse multiple repositories, some marked public and some marked > private. We don't want to introduce changes in the way stuff is > shipped that would break CM3IDE or M3BROWSER. I think the browsing > capabilities in CM3IDE are an outgrowth of the old m3browser and > expand upon it to show dependencies, lists of interfaces/ > implementions imported/exported, etc. etc. CM3IDE also relies on > knowledge of the cm3 file tree to locate stuff and to create new > packages, etc. If we muck around too much with all of this, we risk > breaking CM3IDE or at least having to adapt it to whatever new > structure/rules are in place. > Regards, > Randy Coleburn > > >>> Tony Hosking 7/2/2009 4:08 PM >>> > Sources. For browsing by the various Modula-3 tools. Come to think > of it, that reminds me -- the package browsing tools (eg, m3browser) > rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, > this argues for only moving the .so files to INSTALL_ROOT/lib and > leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived > sources in the pkg/TARGET directories where they currently reside). From rcolebur at scires.com Fri Jul 3 01:14:58 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 19:14:58 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: <4A4D0732.1E75.00D7.1@scires.com> I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release. 1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms. 2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. 3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure: +---foo | +---src | +---NT386 | +---HPPA | \---(...) 4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) 5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure: CM3 +---bin +---doc | +---help | +---pics | +---reference | +---src_reports | \---tutorial +---examples +---lib +---pkg | +---bitvector | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---cm3ide | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---(...) | | +---src | | +---NT386 | | +---HPPA | | \---(...) 6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly. 7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken. 8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed. Hope this info is helpful. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jul 3 03:50:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:50:55 -0700 Subject: [M3devel] ROOT In-Reply-To: <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> Message-ID: <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> In particular I would argue that the directory layout should be made right at link time, into an alternate root. That alternate root possibly be prepopulated with links to or copies of the current good shared repository. Or the compiler should have notion of multiple roots to probe. However running the stuff implies hardlinks that are broken upon write. This scheme works better if source/interfaces are not needed in repository, just to cut down on the size. Are shipped source/interfaces used by compiler, or just the .m3exports/.m3x files? Anyway this is all thinking for a future release, not this year. 'ship' becomes just recursive copy or move.or change roots, plus maybe shipping source/interfaces too, kind of a wart. - Jay (phone) On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > The system used/uses symlinks under the covers. I don't think cm3 > historically supported shared libs on hpux probably because the > bundled compiler does not. Granted my exposure to hpux is only in > recent times. 'standalone' as you define is useful but I think that > reason isn't applicable to anything 'within cm3 itself'. Maybe more > to say later. In particular I think this design we have is flawed. > It's goals are good but can be better achieved slightly differently. > In particular the unshipped and shipped directory layout should be > 'the same' but just differently rooted. Not in this release though. > That let's $origin work better, among other advantages. Related and > possibly solved same IMHO we don't adequately separate source and > output - it should separate across multiple packages not just one at > a time. But again, not on this release. > > - Jay (phone) > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" > wrote: > >> I thought it might be helpful to highlight some of what I've always >> understood as the design for the CM3 package system. So, I pulled >> out my old documentation from Critical Mass as reference. >> >> I offer the following information to see if this discussion thread >> concurs and/or wants to make any changes going forward, esp. as we >> prepare for a new CM3 release. >> >> 1. CM3 takes care to separate source and derived files because >> doing so (a) isolates source files for backup, revision control, >> and searching; and (b) enables sharing the same source tree across >> operating systems and architectures, without confusing object files >> from different platforms. >> >> 2. Each package resides in a directory, with sources in a source >> subdirectory ("src"), and generated files in a derived subdirectory >> named to denote the platform on which the sources were built, e.g., >> "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. >> >> 3. Each developer can have multiple private packages, each stored >> wherever desired in the filesystem. A private package named "foo" >> would have the following filesystem structure: >> +---foo >> | +---src >> | +---NT386 >> | +---HPPA >> | \---(...) >> >> 4. For each CM3 installation, there is one public package >> repository that is available to all developers. When you ship a >> [private] package, you make that package available to other >> packages (and developers) via this public package repository. The >> idea is that as a developer you would test your package in your >> private repository before shipping it to the public repository. >> (Sometimes m3overrides were needed when testing several related >> private packages before shipping them.) >> >> 5. A typical CM3 installation is rooted at a given point in the >> file system and contains the following folder structure: >> CM3 >> +---bin >> +---doc >> | +---help >> | +---pics >> | +---reference >> | +---src_reports >> | \---tutorial >> +---examples >> +---lib >> +---pkg >> | +---bitvector >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> | +---cm3ide >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> | +---(...) >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> >> 6. In the past, the environment variable INSTALL_ROOT pointed to >> the root of the CM3 tree in the file system. I think this variable >> is ambiguously named and that we should change it to >> CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 >> installations (perhaps for different releases), one would simply >> need to change the CM3_INSTALL_ROOT variable to point to the >> desired installation for use at any particular point in time. For >> this to work, all other variables cue off of CM3_INSTALL_ROOT. I >> know that for the old cm3.cfg file, this was indeed the behavior. >> Then, if someone had a special situation, they could override the >> "cueing" behavior for any particular variable simply by changing >> its definition on the fly. >> >> 7. Now, I also understand some (but not all) of what Jay is saying >> about the library paths. Back in the old cm3 v4.1 days, I had both >> HPPA and NT386 derived files for the same set of sources. For >> Windows, the shipped exe and dll files went into the public >> repository and you needed to have the CM3/bin folder on your path. >> For private exe and dlls, you typically just ran them out of the >> private package's derived NT386 folder. On HPPA, there were some >> places in the file system that contained static libraries and >> shared libraries, plus then you had the libraries built using CM3. >> Again, the CM3 libraries went to the public repository and there >> were environment variables to facilitate finding the rest, >> including LD_LIBRARY_PATH. Now, from what Jay is saying, the >> variety of operating environments seems to cloud up all this. I >> know I'm a bit rusty wrt all the various unix variants out there, >> but I recall that v4.1 worked out-of-the-box for both NT386 and >> HPPA with respect to all this library path stuff and I didn't have >> to make any symbolic links nor any hard links to make it work. >> IMO, links are bad and too easily broken. >> >> 8. As for "build_standalone", I know there are various build/ >> bootstrap reasons why some parts of CM3 had to be built this way. >> But, for me, I've often used this feature for utility-type programs >> to make it easier to distribute them. I can simply distribute the >> one executable file without having to worry that the target system >> might not have the right DLLs or the right shared libraries in the >> right locations. For production code, I've always built an >> installation program or an installation script that installed all >> my executables and shared libraries in a folder structure rooted at >> a particular point chosen by the end user. Then, my programs >> always launched and used relative paths from the install location >> to find everything they needed. >> >> Hope this info is helpful. >> >> Regards, >> Randy Coleburn >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 03:57:38 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:57:38 -0700 Subject: [M3devel] ROOT In-Reply-To: <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> Message-ID: <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> Ps this would also obsolete m3overrides, providing similar but better functionality, no need to encode the source structure in all those little extra files. - Jay (phone) On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > In particular I would argue that the directory layout should be made > right at link time, into an alternate root. That alternate root > possibly be prepopulated with links to or copies of the current good > shared repository. Or the compiler should have notion of multiple > roots to probe. However running the stuff implies hardlinks that are > broken upon write. This scheme works better if source/interfaces are > not needed in repository, just to cut down on the size. Are shipped > source/interfaces used by compiler, or just the .m3exports/.m3x > files? Anyway this is all thinking for a future release, not this > year. 'ship' becomes just recursive copy or move.or change roots, > plus maybe shipping source/interfaces too, kind of a wart. > > - Jay (phone) > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > >> The system used/uses symlinks under the covers. I don't think cm3 >> historically supported shared libs on hpux probably because the >> bundled compiler does not. Granted my exposure to hpux is only in >> recent times. 'standalone' as you define is useful but I think that >> reason isn't applicable to anything 'within cm3 itself'. Maybe more >> to say later. In particular I think this design we have is flawed. >> It's goals are good but can be better achieved slightly >> differently. In particular the unshipped and shipped directory >> layout should be 'the same' but just differently rooted. Not in >> this release though. That let's $origin work better, among other >> advantages. Related and possibly solved same IMHO we don't >> adequately separate source and output - it should separate across >> multiple packages not just one at a time. But again, not on this >> release. >> >> - Jay (phone) >> >> On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" >> wrote: >> >>> I thought it might be helpful to highlight some of what I've >>> always understood as the design for the CM3 package system. So, I >>> pulled out my old documentation from Critical Mass as reference. >>> >>> I offer the following information to see if this discussion thread >>> concurs and/or wants to make any changes going forward, esp. as we >>> prepare for a new CM3 release. >>> >>> 1. CM3 takes care to separate source and derived files because >>> doing so (a) isolates source files for backup, revision control, >>> and searching; and (b) enables sharing the same source tree across >>> operating systems and architectures, without confusing object >>> files from different platforms. >>> >>> 2. Each package resides in a directory, with sources in a source >>> subdirectory ("src"), and generated files in a derived >>> subdirectory named to denote the platform on which the sources >>> were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. >>> >>> 3. Each developer can have multiple private packages, each stored >>> wherever desired in the filesystem. A private package named "foo" >>> would have the following filesystem structure: >>> +---foo >>> | +---src >>> | +---NT386 >>> | +---HPPA >>> | \---(...) >>> >>> 4. For each CM3 installation, there is one public package >>> repository that is available to all developers. When you ship a >>> [private] package, you make that package available to other >>> packages (and developers) via this public package repository. The >>> idea is that as a developer you would test your package in your >>> private repository before shipping it to the public repository. >>> (Sometimes m3overrides were needed when testing several related >>> private packages before shipping them.) >>> >>> 5. A typical CM3 installation is rooted at a given point in the >>> file system and contains the following folder structure: >>> CM3 >>> +---bin >>> +---doc >>> | +---help >>> | +---pics >>> | +---reference >>> | +---src_reports >>> | \---tutorial >>> +---examples >>> +---lib >>> +---pkg >>> | +---bitvector >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> | +---cm3ide >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> | +---(...) >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> >>> 6. In the past, the environment variable INSTALL_ROOT pointed to >>> the root of the CM3 tree in the file system. I think this >>> variable is ambiguously named and that we should change it to >>> CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 >>> installations (perhaps for different releases), one would simply >>> need to change the CM3_INSTALL_ROOT variable to point to the >>> desired installation for use at any particular point in time. For >>> this to work, all other variables cue off of CM3_INSTALL_ROOT. I >>> know that for the old cm3.cfg file, this was indeed the behavior. >>> Then, if someone had a special situation, they could override the >>> "cueing" behavior for any particular variable simply by changing >>> its definition on the fly. >>> >>> 7. Now, I also understand some (but not all) of what Jay is >>> saying about the library paths. Back in the old cm3 v4.1 days, I >>> had both HPPA and NT386 derived files for the same set of >>> sources. For Windows, the shipped exe and dll files went into the >>> public repository and you needed to have the CM3/bin folder on >>> your path. For private exe and dlls, you typically just ran them >>> out of the private package's derived NT386 folder. On HPPA, there >>> were some places in the file system that contained static >>> libraries and shared libraries, plus then you had the libraries >>> built using CM3. Again, the CM3 libraries went to the public >>> repository and there were environment variables to facilitate >>> finding the rest, including LD_LIBRARY_PATH. Now, from what Jay >>> is saying, the variety of operating environments seems to cloud up >>> all this. I know I'm a bit rusty wrt all the various unix >>> variants out there, but I recall that v4.1 worked out-of-the-box >>> for both NT386 and HPPA with respect to all this library path >>> stuff and I didn't have to make any symbolic links nor any hard >>> links to make it work. IMO, links are bad and too easily broken. >>> >>> 8. As for "build_standalone", I know there are various build/ >>> bootstrap reasons why some parts of CM3 had to be built this way. >>> But, for me, I've often used this feature for utility-type >>> programs to make it easier to distribute them. I can simply >>> distribute the one executable file without having to worry that >>> the target system might not have the right DLLs or the right >>> shared libraries in the right locations. For production code, >>> I've always built an installation program or an installation >>> script that installed all my executables and shared libraries in a >>> folder structure rooted at a particular point chosen by the end >>> user. Then, my programs always launched and used relative paths >>> from the install location to find everything they needed. >>> >>> Hope this info is helpful. >>> >>> Regards, >>> Randy Coleburn >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 03:36:16 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:36:16 -0700 Subject: [M3devel] ROOT In-Reply-To: <4A4D0732.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> Message-ID: <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release. - Jay (phone) On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > I thought it might be helpful to highlight some of what I've always > understood as the design for the CM3 package system. So, I pulled > out my old documentation from Critical Mass as reference. > > I offer the following information to see if this discussion thread > concurs and/or wants to make any changes going forward, esp. as we > prepare for a new CM3 release. > > 1. CM3 takes care to separate source and derived files because > doing so (a) isolates source files for backup, revision control, and > searching; and (b) enables sharing the same source tree across > operating systems and architectures, without confusing object files > from different platforms. > > 2. Each package resides in a directory, with sources in a source > subdirectory ("src"), and generated files in a derived subdirectory > named to denote the platform on which the sources were built, e.g., > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > 3. Each developer can have multiple private packages, each stored > wherever desired in the filesystem. A private package named "foo" > would have the following filesystem structure: > +---foo > | +---src > | +---NT386 > | +---HPPA > | \---(...) > > 4. For each CM3 installation, there is one public package > repository that is available to all developers. When you ship a > [private] package, you make that package available to other packages > (and developers) via this public package repository. The idea is > that as a developer you would test your package in your private > repository before shipping it to the public repository. (Sometimes > m3overrides were needed when testing several related private > packages before shipping them.) > > 5. A typical CM3 installation is rooted at a given point in the > file system and contains the following folder structure: > CM3 > +---bin > +---doc > | +---help > | +---pics > | +---reference > | +---src_reports > | \---tutorial > +---examples > +---lib > +---pkg > | +---bitvector > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---cm3ide > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---(...) > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > > 6. In the past, the environment variable INSTALL_ROOT pointed to > the root of the CM3 tree in the file system. I think this variable > is ambiguously named and that we should change it to > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > installations (perhaps for different releases), one would simply > need to change the CM3_INSTALL_ROOT variable to point to the desired > installation for use at any particular point in time. For this to > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > for the old cm3.cfg file, this was indeed the behavior. Then, if > someone had a special situation, they could override the "cueing" > behavior for any particular variable simply by changing its > definition on the fly. > > 7. Now, I also understand some (but not all) of what Jay is saying > about the library paths. Back in the old cm3 v4.1 days, I had both > HPPA and NT386 derived files for the same set of sources. For > Windows, the shipped exe and dll files went into the public > repository and you needed to have the CM3/bin folder on your path. > For private exe and dlls, you typically just ran them out of the > private package's derived NT386 folder. On HPPA, there were some > places in the file system that contained static libraries and shared > libraries, plus then you had the libraries built using CM3. Again, > the CM3 libraries went to the public repository and there were > environment variables to facilitate finding the rest, including > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > operating environments seems to cloud up all this. I know I'm a bit > rusty wrt all the various unix variants out there, but I recall that > v4.1 worked out-of-the-box for both NT386 and HPPA with respect to > all this library path stuff and I didn't have to make any symbolic > links nor any hard links to make it work. IMO, links are bad and > too easily broken. > > 8. As for "build_standalone", I know there are various build/ > bootstrap reasons why some parts of CM3 had to be built this way. > But, for me, I've often used this feature for utility-type programs > to make it easier to distribute them. I can simply distribute the > one executable file without having to worry that the target system > might not have the right DLLs or the right shared libraries in the > right locations. For production code, I've always built an > installation program or an installation script that installed all my > executables and shared libraries in a folder structure rooted at a > particular point chosen by the end user. Then, my programs always > launched and used relative paths from the install location to find > everything they needed. > > Hope this info is helpful. > > Regards, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Fri Jul 3 08:40:27 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 3 Jul 2009 02:40:27 -0400 Subject: [M3devel] ROOT In-Reply-To: <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> Message-ID: <4A4D6F9A.1E75.00D7.1@scires.com> Jay: Not sure I fully appreciate/understand your last 3 posts below. I'd also like to hear what Tony and Olaf think about all this. Regards, Randy >>> 7/2/2009 9:57 PM >>> Ps this would also obsolete m3overrides, providing similar but better functionality, no need to encode the source structure in all those little extra files. - Jay (phone) On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: In particular I would argue that the directory layout should be made right at link time, into an alternate root. That alternate root possibly be prepopulated with links to or copies of the current good shared repository. Or the compiler should have notion of multiple roots to probe. However running the stuff implies hardlinks that are broken upon write. This scheme works better if source/interfaces are not needed in repository, just to cut down on the size. Are shipped source/interfaces used by compiler, or just the .m3exports/.m3x files? Anyway this is all thinking for a future release, not this year. 'ship' becomes just recursive copy or move.or change roots, plus maybe shipping source/interfaces too, kind of a wart. - Jay (phone) On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release. - Jay (phone) On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release. 1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms. 2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. 3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure: +---foo | +---src | +---NT386 | +---HPPA | \---(...) 4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) 5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure: CM3 +---bin +---doc | +---help | +---pics | +---reference | +---src_reports | \---tutorial +---examples +---lib +---pkg | +---bitvector | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---cm3ide | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---(...) | | +---src | | +---NT386 | | +---HPPA | | \---(...) 6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly. 7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken. 8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed. Hope this info is helpful. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From rcolebur at scires.com Fri Jul 3 08:42:50 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 3 Jul 2009 02:42:50 -0400 Subject: [M3devel] reminder about email replies to this list Message-ID: <4A4D702A.1E75.00D7.1@scires.com> I notice that I am getting two and three email messages containing the same text. I suspect that folks are just choosing to "reply all". Please note that you should really just reply to m3devel. That way we don't get multiple copies. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Fri Jul 3 11:22:05 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 11:22:05 +0200 Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT In-Reply-To: <4A4D6F9A.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> <4A4D6F9A.1E75.00D7.1@scires.com> Message-ID: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> Quoting Randy Coleburn : > Jay: > > Not sure I fully appreciate/understand your last 3 posts below. > > I'd also like to hear what Tony and Olaf think about all this. I think Jay chiefly opts for a long unimplemented wish of mine: a hierarchy of repositories that is searched by the M3 builder. Imagine that you can have one global repository, which contains some standard and base packages and tools, and several project repositories, each of which is used by teams whose members all have private repositories for their own test and development purposes. A note on terminology: I don't really like to use the term `repository' here, as it is usually used in connection with version control systems. In ComPact, a tool developed and used years ago by Elego, we called these `repositories' which contained pre-built packages `package pools' or just `pools'. So I'll use that term instead of repository from now on. The CM3 builder needs to be extended to search a set of pools instead of just one (INSTALL_ROOT). This could be expressed by a CM3_POOL_PATH, similar to the Java class path: CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 To satisfy package imports, the builder would start searching in the first pool and continue until it has found an appropriate package. This way local or project changes could easily be tested and integrated before being `promoted' to a higher level. For backward compatibility reasons, there should be a default pool (/usr/local/cm3) which is used when nothing else is defined. Shipping of packages would by default use the first pool found in the CM3_POOL_PATH. The second extension needed would be the `promote' operation, which ships a package from one pool to another pool. Of course CM3 would need to make sure that all dependencies are correct and the shipped package does actually work within the new context (the destination pool's packages). If the package structure is the same in the workspace and in package pools, standard shipping and promoting operations would just be file copies (after appropriate correctness checks) as Jay says. Also, as Jay noticed, the `hack' of m3overrides wouldn't be necessary any more. I don't think this would be too difficult to implement. I just haven't found the time to do it yet ;-) Some further remarks to topics touched below: Shared libraries weren't in wide-spread use when the M3 package systme was designed. Only few of the DEC SRC targets actually contained support for them. IMO it's OK to ship them all to one directory, but to make things work for multi-architecture pools, we'd need to distinguish the library and binary paths there, too. So we'd have something like root/pkg/pkg-a/src /NT386 /I386_DARWIN /pkg-b/src /NT386 /I386_DARWIN /man /bin/NT386 /I386_DARWIN ... /lib/NT386 /I386_DARWIN ... Symbolic links were used for dynamic libraries by the related quake code as long as I remember. The variable ROOT is legacy, I think it was used for overrides even by DEC SRC. I've got no objection to rename it, but, as described above, we should rather make it vanish. Olaf > Regards, > Randy > >>>> 7/2/2009 9:57 PM >>> > > Ps this would also obsolete m3overrides, providing similar but > better functionality, no need to encode the source structure in all > those little extra files. > > - Jay (phone) > > On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > > > In particular I would argue that the directory layout should be made > right at link time, into an alternate root. That alternate root > possibly be prepopulated with links to or copies of the current good > shared repository. Or the compiler should have notion of multiple > roots to probe. However running the stuff implies hardlinks that are > broken upon write. This scheme works better if source/interfaces > are not needed in repository, just to cut down on the size. Are > shipped source/interfaces used by compiler, or just the > .m3exports/.m3x files? Anyway this is all thinking for a future > release, not this year. 'ship' becomes just recursive copy or > move.or change roots, plus maybe shipping source/interfaces too, > kind of a wart. > > - Jay (phone) > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > > > The system used/uses symlinks under the covers. I don't think cm3 > historically supported shared libs on hpux probably because the > bundled compiler does not. Granted my exposure to hpux is only in > recent times. 'standalone' as you define is useful but I think that > reason isn't applicable to anything 'within cm3 itself'. Maybe more > to say later. In particular I think this design we have is flawed. > It's goals are good but can be better achieved slightly differently. > In particular the unshipped and shipped directory layout should be > 'the same' but just differently rooted. Not in this release though. > That let's $origin work better, among other advantages. Related and > possibly solved same IMHO we don't adequately separate source and > output - it should separate across multiple packages not just one at > a time. But again, not on this release. > > - Jay (phone) > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > > > I thought it might be helpful to highlight some of what I've always > understood as the design for the CM3 package system. So, I pulled > out my old documentation from Critical Mass as reference. > > I offer the following information to see if this discussion thread > concurs and/or wants to make any changes going forward, esp. as we > prepare for a new CM3 release. > > 1. CM3 takes care to separate source and derived files because > doing so (a) isolates source files for backup, revision control, and > searching; and (b) enables sharing the same source tree across > operating systems and architectures, without confusing object files > from different platforms. > > 2. Each package resides in a directory, with sources in a source > subdirectory ("src"), and generated files in a derived subdirectory > named to denote the platform on which the sources were built, e.g., > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > 3. Each developer can have multiple private packages, each stored > wherever desired in the filesystem. A private package named "foo" > would have the following filesystem structure: > +---foo > | +---src > | +---NT386 > | +---HPPA > | \---(...) > > 4. For each CM3 installation, there is one public package > repository that is available to all developers. When you ship a > [private] package, you make that package available to other packages > (and developers) via this public package repository. The idea is > that as a developer you would test your package in your private > repository before shipping it to the public repository. (Sometimes > m3overrides were needed when testing several related private > packages before shipping them.) > > 5. A typical CM3 installation is rooted at a given point in the > file system and contains the following folder structure: > CM3 > +---bin > +---doc > | +---help > | +---pics > | +---reference > | +---src_reports > | \---tutorial > +---examples > +---lib > +---pkg > | +---bitvector > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---cm3ide > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---(...) > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > > 6. In the past, the environment variable INSTALL_ROOT pointed to > the root of the CM3 tree in the file system. I think this variable > is ambiguously named and that we should change it to > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > installations (perhaps for different releases), one would simply > need to change the CM3_INSTALL_ROOT variable to point to the desired > installation for use at any particular point in time. For this to > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > for the old cm3.cfg file, this was indeed the behavior. Then, if > someone had a special situation, they could override the "cueing" > behavior for any particular variable simply by changing its > definition on the fly. > > 7. Now, I also understand some (but not all) of what Jay is saying > about the library paths. Back in the old cm3 v4.1 days, I had both > HPPA and NT386 derived files for the same set of sources. For > Windows, the shipped exe and dll files went into the public > repository and you needed to have the CM3/bin folder on your path. > For private exe and dlls, you typically just ran them out of the > private package's derived NT386 folder. On HPPA, there were some > places in the file system that contained static libraries and shared > libraries, plus then you had the libraries built using CM3. Again, > the CM3 libraries went to the public repository and there were > environment variables to facilitate finding the rest, including > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > operating environments seems to cloud up all this. I know I'm a bit > rusty wrt all the various unix variants out there, but I recall > that v4.1 worked out-of-the-box for both NT386 and HPPA with > respect to all this library path stuff and I didn't have to make > any symbolic links nor any hard links to make it work. IMO, links > are bad and too easily broken. > > 8. As for "build_standalone", I know there are various > build/bootstrap reasons why some parts of CM3 had to be built this > way. But, for me, I've often used this feature for utility-type > programs to make it easier to distribute them. I can simply > distribute the one executable file without having to worry that the > target system might not have the right DLLs or the right shared > libraries in the right locations. For production code, I've always > built an installation program or an installation script that > installed all my executables and shared libraries in a folder > structure rooted at a particular point chosen by the end user. > Then, my programs always launched and used relative paths from the > install location to find everything they needed. > > Hope this info is helpful. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 3 13:25:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 11:25:28 +0000 Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT In-Reply-To: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> <4A4D6F9A.1E75.00D7.1@scires.com> <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> Message-ID: [didn't really finish editing this..ran out of energe..] Cool. > For backward compatibility reasons, there should be a default pool > (/usr/local/cm3) which is used when nothing else is defined. "I THINK:" (ie: I'm not sure, winging it..) The last pool searched would correspond to where the compiler is. The first one might be ROOT/pkg. I'd kind of like it to be outside ROOT entirely, but having it be one toplevel directory in ROOT is progress. ? An initial version that only supports two pools doesn't rqeuire another setting. ? You know, do-cm3-all realclean would be rm -rf firstpool and optionally "clone" or "populate" firstpool from secondpool. Clone/populate might be separate step, such as if I'm cleaning now, but not building till later. ? A system with multiple pools requires more thought than just two pools. Like, well, you need more parameters. In a two pool system, promote is always from "private" to "public". In a multi pool system, you need to specify earlier pool and later pool, and all the "in between" pools need to be updated as well, or possibly deleted. Actually a multi pool system..I'm not sure this works well. In particular because of $origin. In particular because the search for shared libraries doesn't necessarily follow analogously to cm3's search for packages. Well, ok, I admit, what probably works well is CM3_POOLs=pool1;pool2;pool3 LD_LIBRARY_PATH=pool1/lib;pool2/lib:pool3/lib Then you can have an arbitrary number of pools and they can all be sparse and you can imagine promoting just a package at a time. If you use $origin, pool/lib can't be sparse. Perhaps just pool/lib, but all the rest can be sparse. Do you promote packages or pools? I think you actually promote entire pools. Aha, see, this solves another problem. This solves cm3 being dynamically linked. Because you promote an entire pool at a time, multiple packages simultaneously, you don't have a new cm3 using an old m3core, because you would build both before any promote. This also fixes the problem where cm3 can't ship itself, because, something like, you never run anything in the first pool. (Similarly it removes the need to build things build_standalone because they run "unshipped". In fact, it makes it so runpath is just $origin/../lib is ok, it removes the problem of unshipped binaries living in a directory layout vs. shipped binaries). That defers to the problem. cm3 might be unable to promote itself. However, first of all, one many systems even NT you can rename and replace. Subsequent invocations can look for and delete the renamed copies. Also, promote might be a wrapper .sh/.cmd, runs the executable, which does most of the work, and leaves behind another .sh/.cmd for the wrapper to run as its last step. Any build output that is "shipped" today would instead be written to the first pool. Non-shipped build outputs, not sure. .o/.mo/.io files. There would probably be another "root" to indicated where unshipped outputs go. That way the entire source tree is kept clean, not just individual packages. > IMO it's OK to ship them all to one directory, but to make things > work for multi-architecture pools, we'd need to distinguish the > library and binary paths there, too. So we'd have something like This is a long-standing dilemna of mine. If multi-architecture pools are the goal, or you just use different roots. Or at least if you have multi-architecture host pools, or only multi-targets. Specifically, bin and lib historically lack architecture, while pkg has it. This should suffice for such a pool to target multiple architectures but not host on multiple architectures. I've long though that maybe root/bin should only contain .cmd/.py/.sh files that determine their host architecture and then run root/pkg/foo/target/foo. Note that this breaks $origin. You could use root/bin/target/foo, root/lib/target/foo and $origin/../../lib but I worry when there are too many ".." in $origin, you run the risk of "escaping" away from "your files" and out into whatever is in the file system. This is a constant dilemna for me because I mostly use a host that supports three Modula-3 hosts. My installation is at c:\cm3 and sometimes c:\cm3\bin\cm3.exe is Cygwin, sometimes it is NT386, and Interix uses c:\cm3\bin\cm3 with no extension. I don't have a clean workflow here. Either I should have c:\cm3 (native), c:\cm3.cygwin, c:\cm3.interix, or I should have c:\cm3\bin\nt386\cm3, c:\cm3\bin\cygwin\cm3, c:\cm3\bin\interix\cm3, or somesuch. Again, though, $origin is a factor here. c:\cm3.cygwin et. al. requires no changes and no concert wrt $origin. Olaf below advocates something more like c:\cm3\bin\nt386\cm3 and I don't disagree, I'm just not sure. "Repository" has many uses. It is "a place you put things". Often it is more like "well structured part of the file system", or deliberately structured. A pool is more like "a collection from which to draw stuff". - Jay > Date: Fri, 3 Jul 2009 11:22:05 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT > > Quoting Randy Coleburn : > > > Jay: > > > > Not sure I fully appreciate/understand your last 3 posts below. > > > > I'd also like to hear what Tony and Olaf think about all this. > > I think Jay chiefly opts for a long unimplemented wish of mine: > a hierarchy of repositories that is searched by the M3 builder. > Imagine that you can have one global repository, which contains > some standard and base packages and tools, and several project > repositories, each of which is used by teams whose members all have > private repositories for their own test and development purposes. > > A note on terminology: I don't really like to use the term > `repository' here, as it is usually used in connection with version > control systems. In ComPact, a tool developed and used years ago by > Elego, we called these `repositories' which contained pre-built packages > `package pools' or just `pools'. So I'll use that term instead of > repository from now on. > > The CM3 builder needs to be extended to search a set of pools > instead of just one (INSTALL_ROOT). This could be expressed by > a CM3_POOL_PATH, similar to the Java class path: > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 > > To satisfy package imports, the builder would start searching in the > first pool and continue until it has found an appropriate package. > This way local or project changes could easily be tested and integrated > before being `promoted' to a higher level. > > For backward compatibility reasons, there should be a default pool > (/usr/local/cm3) which is used when nothing else is defined. > > Shipping of packages would by default use the first pool found in the > CM3_POOL_PATH. > > The second extension needed would be the `promote' operation, which > ships a package from one pool to another pool. Of course CM3 would > need to make sure that all dependencies are correct and the shipped > package does actually work within the new context (the destination > pool's packages). > > If the package structure is the same in the workspace and in package > pools, standard shipping and promoting operations would just be > file copies (after appropriate correctness checks) as Jay says. > > Also, as Jay noticed, the `hack' of m3overrides wouldn't be > necessary any more. > > I don't think this would be too difficult to implement. I just haven't > found the time to do it yet ;-) > > Some further remarks to topics touched below: > > Shared libraries weren't in wide-spread use when the M3 package > systme was designed. Only few of the DEC SRC targets actually > contained support for them. > > IMO it's OK to ship them all to one directory, but to make things > work for multi-architecture pools, we'd need to distinguish the > library and binary paths there, too. So we'd have something like > > root/pkg/pkg-a/src > /NT386 > /I386_DARWIN > /pkg-b/src > /NT386 > /I386_DARWIN > /man > /bin/NT386 > /I386_DARWIN > ... > /lib/NT386 > /I386_DARWIN > ... > > Symbolic links were used for dynamic libraries by the related quake > code as long as I remember. > > The variable ROOT is legacy, I think it was used for overrides even > by DEC SRC. I've got no objection to rename it, but, as described above, > we should rather make it vanish. > > Olaf > > > Regards, > > Randy > > > >>>> 7/2/2009 9:57 PM >>> > > > > Ps this would also obsolete m3overrides, providing similar but > > better functionality, no need to encode the source structure in all > > those little extra files. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > > > > > > In particular I would argue that the directory layout should be made > > right at link time, into an alternate root. That alternate root > > possibly be prepopulated with links to or copies of the current good > > shared repository. Or the compiler should have notion of multiple > > roots to probe. However running the stuff implies hardlinks that are > > broken upon write. This scheme works better if source/interfaces > > are not needed in repository, just to cut down on the size. Are > > shipped source/interfaces used by compiler, or just the > > .m3exports/.m3x files? Anyway this is all thinking for a future > > release, not this year. 'ship' becomes just recursive copy or > > move.or change roots, plus maybe shipping source/interfaces too, > > kind of a wart. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > > > > > > The system used/uses symlinks under the covers. I don't think cm3 > > historically supported shared libs on hpux probably because the > > bundled compiler does not. Granted my exposure to hpux is only in > > recent times. 'standalone' as you define is useful but I think that > > reason isn't applicable to anything 'within cm3 itself'. Maybe more > > to say later. In particular I think this design we have is flawed. > > It's goals are good but can be better achieved slightly differently. > > In particular the unshipped and shipped directory layout should be > > 'the same' but just differently rooted. Not in this release though. > > That let's $origin work better, among other advantages. Related and > > possibly solved same IMHO we don't adequately separate source and > > output - it should separate across multiple packages not just one at > > a time. But again, not on this release. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > > > > > > I thought it might be helpful to highlight some of what I've always > > understood as the design for the CM3 package system. So, I pulled > > out my old documentation from Critical Mass as reference. > > > > I offer the following information to see if this discussion thread > > concurs and/or wants to make any changes going forward, esp. as we > > prepare for a new CM3 release. > > > > 1. CM3 takes care to separate source and derived files because > > doing so (a) isolates source files for backup, revision control, and > > searching; and (b) enables sharing the same source tree across > > operating systems and architectures, without confusing object files > > from different platforms. > > > > 2. Each package resides in a directory, with sources in a source > > subdirectory ("src"), and generated files in a derived subdirectory > > named to denote the platform on which the sources were built, e.g., > > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > > > 3. Each developer can have multiple private packages, each stored > > wherever desired in the filesystem. A private package named "foo" > > would have the following filesystem structure: > > +---foo > > | +---src > > | +---NT386 > > | +---HPPA > > | \---(...) > > > > 4. For each CM3 installation, there is one public package > > repository that is available to all developers. When you ship a > > [private] package, you make that package available to other packages > > (and developers) via this public package repository. The idea is > > that as a developer you would test your package in your private > > repository before shipping it to the public repository. (Sometimes > > m3overrides were needed when testing several related private > > packages before shipping them.) > > > > 5. A typical CM3 installation is rooted at a given point in the > > file system and contains the following folder structure: > > CM3 > > +---bin > > +---doc > > | +---help > > | +---pics > > | +---reference > > | +---src_reports > > | \---tutorial > > +---examples > > +---lib > > +---pkg > > | +---bitvector > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > | +---cm3ide > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > | +---(...) > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > > > 6. In the past, the environment variable INSTALL_ROOT pointed to > > the root of the CM3 tree in the file system. I think this variable > > is ambiguously named and that we should change it to > > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > > installations (perhaps for different releases), one would simply > > need to change the CM3_INSTALL_ROOT variable to point to the desired > > installation for use at any particular point in time. For this to > > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > > for the old cm3.cfg file, this was indeed the behavior. Then, if > > someone had a special situation, they could override the "cueing" > > behavior for any particular variable simply by changing its > > definition on the fly. > > > > 7. Now, I also understand some (but not all) of what Jay is saying > > about the library paths. Back in the old cm3 v4.1 days, I had both > > HPPA and NT386 derived files for the same set of sources. For > > Windows, the shipped exe and dll files went into the public > > repository and you needed to have the CM3/bin folder on your path. > > For private exe and dlls, you typically just ran them out of the > > private package's derived NT386 folder. On HPPA, there were some > > places in the file system that contained static libraries and shared > > libraries, plus then you had the libraries built using CM3. Again, > > the CM3 libraries went to the public repository and there were > > environment variables to facilitate finding the rest, including > > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > > operating environments seems to cloud up all this. I know I'm a bit > > rusty wrt all the various unix variants out there, but I recall > > that v4.1 worked out-of-the-box for both NT386 and HPPA with > > respect to all this library path stuff and I didn't have to make > > any symbolic links nor any hard links to make it work. IMO, links > > are bad and too easily broken. > > > > 8. As for "build_standalone", I know there are various > > build/bootstrap reasons why some parts of CM3 had to be built this > > way. But, for me, I've often used this feature for utility-type > > programs to make it easier to distribute them. I can simply > > distribute the one executable file without having to worry that the > > target system might not have the right DLLs or the right shared > > libraries in the right locations. For production code, I've always > > built an installation program or an installation script that > > installed all my executables and shared libraries in a folder > > structure rooted at a particular point chosen by the end user. > > Then, my programs always launched and used relative paths from the > > install location to find everything they needed. > > > > Hope this info is helpful. > > > > Regards, > > Randy Coleburn > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 15:46:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 13:46:24 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 15:53:29 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 13:53:29 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 16:19:02 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 14:19:02 +0000 Subject: [M3devel] FW: removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [trying again...truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 18:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 16:14:43 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [trying again again...truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 3 19:44:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 3 Jul 2009 13:44:34 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> Message-ID: On 2 Jul 2009, at 16:23, Jay wrote: > (I just didn't like the link stuff and I still don't understand > what ROOT is there for). > > The point was to add Unix.link where it belongs, m3core, and use it > from where can't depend on new m3core. > And maybe go overboard in sharing the source, to a trivial one > line function (less trivial on Win32, in order to support pre- > Win2000 OS). > The point was to put the files in lib and also leave them in pkg, > without wasting space. > The decision now, which I still have to try, is to stop putting the > files in pkg, so then no hardlink needed. Sounds good. > $origin vs. full paths is still debatable and I still convinced > $origin is the way to go. I agree $origin is best way to go. > I'm also inclined to put $origin and $origin/../lib in rpath, so > backups can flatten the structure to just one directory: > /backup/cm3 > /backup/libm3core.so > /backup/libm3.so Fair enough. > in some /hypothetical future/ where cm3 is dynamically linked. > As long there are no "duplicates" -- files in both bin and lib, the > runpath remains fairly clear/unambiguous. > And even then, the order is pretty clearly left to right.. Not sure I understand. > > - Jay > > > > > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 16:17:54 -0400 > > On 2 Jul 2009, at 16:03, Jay wrote: > > Ok, so I think a very important question is: > > >>> Should users have a choice of where to install? > > Yes! > > >>> What are the reasonable ramifications of someone who makes a > non-default choice? > > /Personally/ I want the choice, esp. if I don't have root access!, > and I don't want to set LD_LIBRARY_PATH. > I want my choice and no negative consequences, and $origin basically > gives me that. > Except NetBSD prior to 5.0. 5.0 already released. > And I guess Solaris prior to 2.7 or such. > > > We do agree on a change vs. previous releases, at least. > And it overlaps with what I did already. > > I think so. (I just didn't like the link stuff and I still don't > understand what ROOT is there for). > > > > > - Jay > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 15:59:25 -0400 > > I agree, LD_LIBRARY_PATH should only be used by power-users in a > pinch during development. > > On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 3 21:36:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 21:36:42 +0200 Subject: [M3devel] building m3gdb on AMD64_LINUX Message-ID: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> building m3gdb on birch ends with gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/tui/tui-winsource.c /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c c-exp.c.tmp -- yacc Cannot open "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" make[2]: *** [c-exp.c] Error 1 make[2]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' make[1]: *** [all-gdb] Error 2 make[1]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' make: *** [all] Error 2 "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile 4 /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args Fatal Error: package build failed Any hints? Wrong yacc? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 3 21:38:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 21:38:54 +0200 Subject: [M3devel] some testing of the new web pages In-Reply-To: References: Message-ID: <20090703213854.76mnwfvjms0w804c@mail.elegosoft.com> Quoting Jay : > I do like the new web pages. > Here are some problems though. Most of the problems below should be fixed now. I've removed packages tcl, mtex and PEX from the distribution, since I don't think they will be useful in their current form. Regards, Olaf > http://www.opencm3.net/releng/collection-core.html > > > go down to m3-sys/cm3 > the builder and freebsd manual page links aren't right. > I think these are maybe just CVS merge conflicts > that happen to be on the packaging machine and > can just be deleted. > > Not clear if most of the gcc links are useful. > > > go down to TCL interfaces for M3 > The browse sources link doesn't work. > Probably related to this not always building and not built. > Probably need to modify this and require people doing package building > to have Tcl installed, maybe even for NT386. > Probably specifically make-dist.sh should set $ENABLE_TCL or somesuch. > (not exactly) > > > The source links present, e.g. the licenses oddly, > but compactly and probably a good thing, e.g.: > http://www.opencm3.net/doc/help/gen_html/tcp/src/common/StreamRdClass.m3.html > Probably an artifact of m3tohtml. > > > http://www.opencm3.net/releng > Go down the righthand side trying everything to one level. > Broken: > http://www.opencm3.net/releng/collection-min.html > http://www.opencm3.net/releng/collection-caltech.html > > > But there is: > http://www.opencm3.net/releng/collection-caltech-parser.html > It contains m3-win/import-libs but shouldn't. > > > I suspect the problems are rooted in: > min is a non-ws package set but not a ws package set. > Because it is overlys small and core subsumes it? > caltech-parser contains a dash. > min to me is specifically enough to start with an old release and > build a current compiler and release -- m3core, libm3, m3cg, cm3, > maybe sysutils > specifically it is the pieces required to compile anything (cm3, m3cg) > and the pieces that an old compiler may not be able to build the > the current versions of (m3core/libm3) that a current compiler will need; > That is, if you want to build natively build the whole system from source, > this is the smallest you can start with. m3cg actually isn't in min but > probably handled specially. > > > Related couments usually but not always > has one extra empty bullet, including but not limited > to when the list is empty: > > http://www.opencm3.net/releng/collection-cvsup.html > http://www.opencm3.net/releng/collection-anim.html > http://www.opencm3.net/releng/collection-cvsup.html > http://www.opencm3.net/releng/collection-database.html > http://www.opencm3.net/releng/collection-demo.html > http://www.opencm3.net/releng/collection-devlib.html > http://www.opencm3.net/releng/collection-game.html > http://www.opencm3.net/releng/collection-gui.html > > This is not all the ones with an extra bullet, and a few > don't have the extra bullet. > > I'm on the fence on the whole ws thing. > Non-ws also has matching source. > The point is to provide the packages both built > and buildable? > If cm3 had a mode that started with assemble then link and ship, > we could cross build all the ws packages, very nice. > > I guess the "real" problem is I feel compelled then to > match this feature in make-dist.py. > > http://www.opencm3.net/releng/collection-tool.html > Try the first few links. > mtex > Browse sources seems incomplete but maybe is right. > The man page links are all broken. > > cmpdir > shows a general pattern: > maybe directories with no files shouldn't be shown? > > http://www.opencm3.net/releng/collection-demo.html > fisheye > The link manual page .makefile isn't right > > > http://www.opencm3.net/releng/collection-devlib.html > m3tk > Several broken manpage links. > > pex > browse sources doesn't work > Probably like Tcl, not always built. > > > http://www.opencm3.net/releng/collection-anim.html > zeus > contains a broken Zeus manual page, I think a CVS conflict file > Might be able to search for this generally in the html. > > http://www.opencm3.net/releng/collection-obliq.html > related documents > first link, to polymtl, broken, sounds promising, maybe > we can find it and host it > > http://www.opencm3.net/releng/collection-m3gdb.html > m3gdb > Like m3cc, maybe some of these READMEs not useful. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Fri Jul 3 23:53:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 03 Jul 2009 16:53:31 -0500 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> Message-ID: <4A4E7DDB.2090107@cox.net> On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc is circuitously symlinked to a script that executes /usr/bin/bison -y. In any case, usually, there is no need to execute yacc when building (m3)gdb, because its output is already present and newer than yacc's input, in this case, c-exp.y. I think this is the way it is in the CVS repository. Did some dates in your source copy get touched? I have no idea where the c-exp.t file it wants is supposed to come from. In a brief look, I didn't find any reference to a *.t file at all, either in the script m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the bison man page on my machine). Maybe original yacc does something with it. I would have thought ylwrap would have been written to work with a number of varieties of yacc and equivalents. Do you have a copy of c-exp.y? I suspect having a newer c-exp.c than c-exp.y will circumvent this problem, but of course we probably want it set up to work when c-exp.c needs to be rebuilt. Olaf Wagner wrote: > building m3gdb on birch ends with > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > -Wformat-nonliteral -Wunused-label -Wunused-function > ../../gdb/gdb/tui/tui-winsource.c > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > c-exp.c.tmp -- yacc > Cannot open > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > make[2]: *** [c-exp.c] Error 1 > make[2]: Leaving directory > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > make[1]: *** [all-gdb] Error 2 > make[1]: Leaving directory > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > make: *** [all] Error 2 > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > --procedure-- -line- -file--- > exec -- > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > 4 > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > Any hints? Wrong yacc? > > Olaf From hendrik at topoi.pooq.com Sat Jul 4 01:12:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Jul 2009 19:12:54 -0400 Subject: [M3devel] multiarch Message-ID: <20090703231254.GA25415@topoi.pooq.com> It seems relevant to out multiarchitecture system that Debian and Ubuntu are currently also struggling to put together a multiarchitecture system. Current thinking seems to be posted at https://wiki.ubuntu.com/MultiarchSpec The stimulus for this work seems to be having 32-bit and 64-bit programs coexist on the same AMD-64 system. But it also deals with questions like MIPS systems having at least three different ABIs. Have a look. -- hendrik From hendrik at topoi.pooq.com Sat Jul 4 01:15:09 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Jul 2009 19:15:09 -0400 Subject: [M3devel] multiarch In-Reply-To: <20090703231254.GA25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> Message-ID: <20090703231509.GB25415@topoi.pooq.com> On Fri, Jul 03, 2009 at 07:12:54PM -0400, hendrik at topoi.pooq.com wrote: > > The stimulus for this work seems to be having 32-bit and 64-bit programs > coexist on the same AMD-64 system. But it also deals with questions > like MIPS systems having at least three different ABIs. They're also considering interpreters like Python to be architectures to be supported. -- hendrik From jay.krell at cornell.edu Sat Jul 4 08:48:19 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 06:48:19 +0000 Subject: [M3devel] multiarch In-Reply-To: <20090703231509.GB25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> Message-ID: The Python thing as I understand it, is that sometimes package foo depends on package bar, and they must be of the same architecture, and sometimes not. Specifically inproc "plugins" require matching architecture, but if I just run an executable, architecture doesn't usually have to match. OpenBSD sets an interesting counterexample -- no biarch/multiarch, just one architecture, "same as it ever was", "no additional complexity", "everything is built from source anyway". - Jay > Date: Fri, 3 Jul 2009 19:15:09 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiarch > > On Fri, Jul 03, 2009 at 07:12:54PM -0400, hendrik at topoi.pooq.com wrote: > > > > The stimulus for this work seems to be having 32-bit and 64-bit programs > > coexist on the same AMD-64 system. But it also deals with questions > > like MIPS systems having at least three different ABIs. > > They're also considering interpreters like Python to be architectures to > be supported. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:28:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <4A4E7DDB.2090107@cox.net> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:33:48 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:33:48 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: It built ok for me a second time. The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb. yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means. You might just try rm -rf m3gdb and cvs -z3 upd -dAP. Maybe there is/was a timestamp problem. As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: Re: [M3devel] building m3gdb on AMD64_LINUX It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:35:51 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:35:51 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: See also C:\dev2\cm3.2\caltech-parser\parserlib\klex\src From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Subject: RE: [M3devel] building m3gdb on AMD64_LINUX Date: Sat, 4 Jul 2009 15:33:48 +0000 It built ok for me a second time. The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb. yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means. You might just try rm -rf m3gdb and cvs -z3 upd -dAP. Maybe there is/was a timestamp problem. As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: Re: [M3devel] building m3gdb on AMD64_LINUX It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 4 19:02:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 4 Jul 2009 13:02:37 -0400 Subject: [M3devel] multiarch In-Reply-To: References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> Message-ID: <20090704170237.GB26647@topoi.pooq.com> On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote: > > The Python thing as I understand it, is that sometimes package foo > depends on package bar, and they must be of the same architecture, and > sometimes not. Specifically inproc "plugins" require matching > architecture, but if I just run an executable, architecture doesn't > usually have to match. An executable has to be one of the architectures the processor will handle. And if it uses shared libraries, they have to have matching architecture. The whole worry about multiarch on Linux AMD-64 is to have a consistent way of identifying the compatible one of a set of same-names libraries, and doing this in such a way that it generalises to more architectures (because they *will* eventually show up) and won't confuse the package manager. I think the real point with python is that python code is architecture-independent, because it's handled by an architecture-dependent interpreter. Which makes it, in effect, an extra architecture that's available everywhere, whether you have an AMD-64 or other multiarch CPU or not. > OpenBSD sets an interesting counterexample -- no biarch/multiarch, > just one architecture, "same as it ever was", "no additional > complexity", everything is built from source anyway". And they probably do not in any way support 32-bit proprietary binary-only device drivers or Flash interpreters or anything like that on AMD-64. Building from source is the traditional Modula-3 way of handling packages. To do this with the Debian package-manager, we'd have to include an install-dependency on cm3-min and let the post-install script use the compiler to compile the package and ship it to the proper place. How to do this multiarch is not clear -- We might end up with a number of different architecture versions of the packages, which have identical contents (they're source code). Being labelled with different architectures might (here's hoping the multiarch project thinks of this) end up invoking the appropriate cm3-min binary ... I suspect having real binary packages for different architectures is the Debian way, however. Using source packages is the norm on gentoo. And cm3-min would have to be binary in any case, otherwise there would be no way to compile it. But the multiarch stuff might indicate where we want to ship our libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 or whatever the multiarch people choose. We're already using similar conventions in the choince of LINUXLIBC6 and such names. -- hendrik From mika at async.caltech.edu Sat Jul 4 19:21:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 04 Jul 2009 10:21:11 -0700 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: Your message of "Sat, 04 Jul 2009 15:33:48 -0000." Message-ID: <200907041721.n64HLCr7015429@taps.cs.caltech.edu> I guarantee that this "yacc" is not a faithful yacc. "k" is the first initial of Karl Papadantonakis, the caltech-parser package's author. Mika Jay writes: >--_682f6248-704f-461d-9237-1a192e95b6fb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >It built ok for me a second time. > >The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-= >cvs-uped m3-sys/m3gdb. > >=20 > >yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. > >=20 > >As long as nothing depend on running it by that name=2C and assuming it isn= >'t a faithful replacement for other Yacc's=2C probably should rename it m3y= >acc=2C or kyacc=2C whatever that means. > >=20 > >You might just try rm -rf m3gdb and cvs -z3 upd -dAP. > >Maybe there is/was a timestamp problem. > >As Rodney said=2C it shouldn't need to run yacc=2C even if your yacc is mes= >sed up. > >=20 > > - Jay > >=20 > > >From: jay.krell at cornell.edu >To: rodney.m.bates at cox.net=3B m3devel at elegosoft.com >Date: Sat=2C 4 Jul 2009 15:28:24 +0000 >Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > > >It built ok for me=2C but there is a suspicous /usr/local/cm3/bin/yacc. >I'm investigating more=2C but maybe not right now. >=20 > - Jay > >=20 >> Date: Fri=2C 3 Jul 2009 16:53:31 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] building m3gdb on AMD64_LINUX >>=20 >> On my AMD64_LINUX machine (Ubuntu 8.04.2)=2C on which m3gdb builds=2C yac= >c >> is circuitously symlinked to a script that executes /usr/bin/bison -y. >>=20 >> In any case=2C usually=2C there is no need to execute yacc when building= >=20 >> (m3)gdb=2C >> because its output is already present and newer than yacc's input=2C in=20 >> this case=2C >> c-exp.y. I think this is the way it is in the CVS repository. Did some=20 >> dates >> in your source copy get touched? >>=20 >> I have no idea where the c-exp.t file it wants is supposed to come from. >> In a brief look=2C I didn't find any reference to a *.t file at all=2C=20 >> either in the script >> m3gdb/gdb/ylwrap=2C nor in the yacc man page (which actually leads to the >> bison man page on my machine). Maybe original yacc does something=20 >> with it.=20 >> I would have thought ylwrap would have been written to work with a number >> of varieties of yacc and equivalents.=20 >>=20 >> Do you have a copy of c-exp.y? >>=20 >> I suspect having a newer c-exp.c than c-exp.y will circumvent this=20 >> problem=2C but >> of course we probably want it set up to work when c-exp.c needs to be=20 >> rebuilt. >>=20 >> Olaf Wagner wrote: >> > building m3gdb on birch ends with >> > >> > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config=20 >> > -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -DHAVE_CONFIG_H=20 >> > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/..=20 >> > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl=20 >> > -I../../gdb/gdb/../intl -DMI_OUT=3D1 -DTUI=3D1 -Wimplicit -Wreturn-type= >=20 >> > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith=20 >> > -Wformat-nonliteral -Wunused-label -Wunused-function=20 >> > ../../gdb/gdb/tui/tui-winsource.c >> > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c=20 >> > c-exp.c.tmp -- yacc >> > Cannot open=20 >> > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp= >.t"=20 >> > >> > make[2]: *** [c-exp.c] Error 1 >> > make[2]: Leaving directory=20 >> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' >> > make[1]: *** [all-gdb] Error 2 >> > make[1]: Leaving directory=20 >> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' >> > make: *** [all] Error 2 >> > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile"=2C line 121: quake= >=20 >> > runtime error: exit 2: make CC=3D"gcc" CFLAGS=3D"-g" MAKEINFO=3Decho >> > >> > --procedure-- -line- -file--- >> > exec -- >> > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> > 4=20 >> > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args >> > >> > Fatal Error: package build failed >> > >> > Any hints? Wrong yacc? >> > >> > Olaf >>=20 > >--_682f6248-704f-461d-9237-1a192e95b6fb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >It built ok for me a second time.
    >The =3Bsecond time I removed /usr/local/cm3/bin from =3B$PATH and d= >eleted and re-cvs-uped m3-sys/m3gdb.
    > =3B
    >yacc =3Bcomes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src.> > =3B
    >As long as nothing depend on running it by that name=2C and assuming it isn= >'t a faithful =3Breplacement for other Yacc's=2C probably should rename= > it m3yacc=2C or kyacc=2C whatever that means.
    > =3B
    >You might just try rm -rf m3gdb and cvs -z3 upd -dAP.
    >Maybe there is/was a timestamp problem.
    >As Rodney said=2C it shouldn't need to run yacc=2C even if your yacc is mes= >sed up.
    > =3B
    > =3B - Jay

     =3B
    >
    >From: jay.krell at cornell.edu
    To: rodney.m.bates at cox.net=3B m3devel at elegos= >oft.com
    Date: Sat=2C 4 Jul 2009 15:28:24 +0000
    Subject: Re: [M3devel]= > building m3gdb on AMD64_LINUX

    > >It built ok for me=2C but there is a =3Bsuspicous /usr/local/cm3/bin/ya= >cc.
    I'm =3Binvestigating more=2C but =3Bmaybe not right now.
    = > =3B
     =3B- Jay

     =3B
    >=3B Date: Fri=2C 3 Jul 2009= > 16:53:31 -0500
    >=3B From: rodney.m.bates at cox.net
    >=3B To: m3deve= >l at elegosoft.com
    >=3B Subject: Re: [M3devel] building m3gdb on AMD64_LI= >NUX
    >=3B
    >=3B On my AMD64_LINUX machine (Ubuntu 8.04.2)=2C on wh= >ich m3gdb builds=2C yacc
    >=3B is circuitously symlinked to a script th= >at executes /usr/bin/bison -y.
    >=3B
    >=3B In any case=2C usually= >=2C there is no need to execute yacc when building
    >=3B (m3)gdb=2C>>=3B because its output is already present and newer than yacc's input= >=2C in
    >=3B this case=2C
    >=3B c-exp.y. I think this is the way i= >t is in the CVS repository. Did some
    >=3B dates
    >=3B in your sou= >rce copy get touched?
    >=3B
    >=3B I have no idea where the c-exp.t= > file it wants is supposed to come from.
    >=3B In a brief look=2C I did= >n't find any reference to a *.t file at all=2C
    >=3B either in the scr= >ipt
    >=3B m3gdb/gdb/ylwrap=2C nor in the yacc man page (which actually = >leads to the
    >=3B bison man page on my machine). Maybe original yacc d= >oes something
    >=3B with it.
    >=3B I would have thought ylwrap wo= >uld have been written to work with a number
    >=3B of varieties of yacc = >and equivalents.
    >=3B
    >=3B Do you have a copy of c-exp.y?
    &g= >t=3B
    >=3B I suspect having a newer c-exp.c than c-exp.y will circumve= >nt this
    >=3B problem=2C but
    >=3B of course we probably want it s= >et up to work when c-exp.c needs to be
    >=3B rebuilt.
    >=3B
    &g= >t=3B Olaf Wagner wrote:
    >=3B >=3B building m3gdb on birch ends with<= >BR>>=3B >=3B
    >=3B >=3B gcc -c -g -I. -I../../gdb/gdb -I../../gdb= >/gdb/config
    >=3B >=3B -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -= >DHAVE_CONFIG_H
    >=3B >=3B -I../../gdb/gdb/../include/opcode -I../../= >gdb/gdb/../readline/..
    >=3B >=3B -I../bfd -I../../gdb/gdb/../bfd -I= >../../gdb/gdb/../include -I../intl
    >=3B >=3B -I../../gdb/gdb/../int= >l -DMI_OUT=3D1 -DTUI=3D1 -Wimplicit -Wreturn-type
    >=3B >=3B -Wcomme= >nt -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith
    >=3B >=3B -Wf= >ormat-nonliteral -Wunused-label -Wunused-function
    >=3B >=3B ../../g= >db/gdb/tui/tui-winsource.c
    >=3B >=3B /bin/sh ../../gdb/gdb/../ylwrap= > ../../gdb/gdb/c-exp.y y.tab.c
    >=3B >=3B c-exp.c.tmp -- yacc
    >= >=3B >=3B Cannot open
    >=3B >=3B "/home/wagner/work/cm3/m3-sys/m3gd= >b/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t"
    >=3B >=3B
    >=3B >=3B= > make[2]: *** [c-exp.c] Error 1
    >=3B >=3B make[2]: Leaving directory= >
    >=3B >=3B `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb'
    = >>=3B >=3B make[1]: *** [all-gdb] Error 2
    >=3B >=3B make[1]: Leav= >ing directory
    >=3B >=3B `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_L= >INUX'
    >=3B >=3B make: *** [all] Error 2
    >=3B >=3B "/home/wagn= >er/work/cm3/m3-sys/m3gdb/src/m3makefile"=2C line 121: quake
    >=3B >= >=3B runtime error: exit 2: make CC=3D"gcc" CFLAGS=3D"-g" MAKEINFO=3Decho>>=3B >=3B
    >=3B >=3B --procedure-- -line- -file---
    >=3B >= >=3B exec -- <=3Bbuiltin>=3B
    >=3B >=3B m3gdb_Run 121 /home/wagner= >/work/cm3/m3-sys/m3gdb/src/m3makefile
    >=3B >=3B include_dir 160 /hom= >e/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile
    >=3B >=3B 4
    >=3B= > >=3B /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args
    >= >=3B >=3B
    >=3B >=3B Fatal Error: package build failed
    >=3B >= >=3B
    >=3B >=3B Any hints? Wrong yacc?
    >=3B >=3B
    >=3B >= >=3B Olaf
    >=3B
    >= > >--_682f6248-704f-461d-9237-1a192e95b6fb_-- From jay.krell at cornell.edu Sat Jul 4 19:24:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 17:24:24 +0000 Subject: [M3devel] multiarch In-Reply-To: <20090704170237.GB26647@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> <20090704170237.GB26647@topoi.pooq.com> Message-ID: I think Python code simply depends on the Python interpreter. I skimmed through the document. The point I gleaned about interpreters is that sometimes a dependency is on an interpreter because the package is a "plugin" or "extension" written in C or such, and sometimes the dependency is because a program is written in "pure" Python (Tcl, Perl, etc.) and just needs "any" interpreter that will run. That is, if I have: hello.py: print("hello") I am dependent on Python, but on an AMD64 system, it can be the x86 Python or AMD64 Python (or heck, Jython or IronPython, implementations in Java and for .NET/Mono). I see your point that Python could be considered an "architecture" and the Python interpreter could be seen as installing the processor. I didn't get that from the spec but should read it more closely. There were some references here to qemu that I didn'd understand but might make sense in that light. That is, maybe, maybe I could have "all architectures" in one file system and maybe some virtualization products use the host file system as a file system and not just store some virtual disk in it. I agree OpenBSD is a bit spartan/draconion/etc. My point about source builds was more to reflect the seeming "OpenBSD way" (Gentoo, SourceMage, etc.), not necessarily what is or should be the Modula-3 way. There's a real dilemna between the two options of binary packages and source builds. They each have advantages/disadvantages. - Jay > Date: Sat, 4 Jul 2009 13:02:37 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiarch > > On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote: > > > > The Python thing as I understand it, is that sometimes package foo > > depends on package bar, and they must be of the same architecture, and > > sometimes not. Specifically inproc "plugins" require matching > > architecture, but if I just run an executable, architecture doesn't > > usually have to match. > > An executable has to be one of the architectures the processor will > handle. And if it uses shared libraries, they have to have matching > architecture. The whole worry about multiarch on Linux AMD-64 is to > have a consistent way of identifying the compatible one of a set > of same-names libraries, and doing this in such a way that it > generalises to more architectures (because they *will* eventually show > up) and won't confuse the package manager. > > I think the real point with python is that python code is > architecture-independent, because it's handled by an > architecture-dependent interpreter. Which makes it, in effect, an > extra architecture that's available everywhere, whether you have an > AMD-64 or other multiarch CPU or not. > > > OpenBSD sets an interesting counterexample -- no biarch/multiarch, > > just one architecture, "same as it ever was", "no additional > > complexity", everything is built from source anyway". > > And they probably do not in any way support 32-bit proprietary > binary-only device drivers or Flash interpreters or anything like that > on AMD-64. > > Building from source is the traditional Modula-3 way of handling > packages. To do this with the Debian package-manager, we'd have to > include an install-dependency on cm3-min and let the post-install > script use the compiler to compile the package and ship it to the > proper place. > > How to do this multiarch is not clear -- We might end up with a number > of different architecture versions of the packages, which have identical > contents (they're source code). Being labelled with different > architectures might (here's hoping the multiarch project thinks of this) > end up invoking the appropriate cm3-min binary ... > > I suspect having real binary packages for different architectures is the > Debian way, however. Using source packages is the norm on gentoo. > And cm3-min would have to be binary in any case, otherwise there would > be no way to compile it. > > But the multiarch stuff might indicate where we want to ship our > libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 > or whatever the multiarch people choose. We're already using similar > conventions in the choince of LINUXLIBC6 and such names. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 4 19:55:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 04 Jul 2009 19:55:21 +0200 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <4A4E7DDB.2090107@cox.net> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: <20090704195521.1g2ictqykgocc0sg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did > some dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. I would have thought ylwrap would have been written to work > with a number > of varieties of yacc and equivalents. Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to > be rebuilt. I now removed everything, including the source, and checked out the package anew. Then the build completed without problems. Thanks for the help, Olaf > Olaf Wagner wrote: >> building m3gdb on birch ends with >> >> gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config >> -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H >> -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. >> -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include >> -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit >> -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses >> -Wpointer-arith -Wformat-nonliteral -Wunused-label >> -Wunused-function ../../gdb/gdb/tui/tui-winsource.c >> /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c >> c-exp.c.tmp -- yacc >> Cannot open >> "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" >> make[2]: *** [c-exp.c] Error 1 >> make[2]: Leaving directory >> `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' >> make[1]: *** [all-gdb] Error 2 >> make[1]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' >> make: *** [all] Error 2 >> "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: >> quake runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo >> >> --procedure-- -line- -file--- >> exec -- >> m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> 4 >> /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args >> >> Fatal Error: package build failed >> >> Any hints? Wrong yacc? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sun Jul 5 21:36:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 5 Jul 2009 15:36:06 -0400 Subject: [M3devel] multiarch In-Reply-To: References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> <20090704170237.GB26647@topoi.pooq.com> Message-ID: <20090705193606.GA31710@topoi.pooq.com> On Sat, Jul 04, 2009 at 05:24:24PM +0000, Jay wrote: > > My point about source builds was more to reflect the seeming "OpenBSD > way" (Gentoo, SourceMage, etc.), not necessarily what is or should be > the Modula-3 way. There's a real dilemna between the two options of > binary packages and source builds. They each have > advantages/disadvantages. One of the differences is that with a binary package, if we fix a big in the compiler package that might affect object code, it is necessary to produce new versions of all the packages that were compiled with it. If we have source packages, the package manager will have to discover that recompilation is necessary. And if we send source packages masquerading as binary packages (via post-install scripts or some such) we have to rerelease identical packages with a new version number, just to ensure recompilation. It seems that the thing to do is build packages that match the target system's predilections. If there are too many target systems, we'll have to do is our way and ignore the target system's conventions. Or maybe provide special packagings for a few important platforms. I gather that Windows is such a system. And I'm hoping Debian is. In any case, the compiler itself will have to be a binary package, because of bootstrapping. I think this discussion is starting to belabor the obvious. Is it useful to go on? I started this thread merely to report that others are starting to deal with multiarchitecture issues, and we might as well be aware of what they're doing. -- hendrik From eiserlohpp at yahoo.com Mon Jul 6 19:00:19 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 6 Jul 2009 10:00:19 -0700 (PDT) Subject: [M3devel] WDROOT private repository not working? Message-ID: <67172.22662.qm@web56806.mail.re3.yahoo.com> Hi Guys, Seeing all the attention placed on creating relative linking, and so forth, I decided to examine the behavior of CM3, when building for a private root. So, I set WDROOT to ${HOME}/m3work in my m3makefile. ---- BEGIN m3makefile ---- %# Time-Space-Position Information (TSPI) library HOME = "/home/peter" WDROOT = HOME & "/m3work" include_dir("xform") % include_dir("smoothing") % include_dir("editing") % include_dir("geoid") % include_dir("testing") ---- EMD m3makefile ---- Then I, attempted to build and ship from there. It said, there was an error ---- BEGIN ERROR MSG ---- peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship --- shipping from ../AMD64_LINUX --- "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/usr/lib/cm3/pkg/tspi": errno=13 --procedure-- -line- -file--- make_dir -- 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP ---- END ERROR MSG ---- Was support for WDROOT removed? Can CM3 support the ability to have a private repository, while also having the public repo? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Mon Jul 6 20:49:21 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 6 Jul 2009 11:49:21 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 33, Issue 25 Message-ID: <208085.23533.qm@web56807.mail.re3.yahoo.com> Hi Olaf, > Date: Fri, 03 Jul 2009 11:22:05 +0200 > From: Olaf Wagner > Subject: [M3devel] Some comments about package structure > and package > pools, was: > Re: ROOT > To: m3devel at elegosoft.com > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com> > Content-Type: text/plain; charset=ISO-8859-15; >The CM3 builder needs to be extended to search a set of pools >instead of just one (INSTALL_ROOT). This could be expressed by >a CM3_POOL_PATH, similar to the Java class path: > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 Yes, I like it. I could then ship my data reduction libraries to an appropriate "pool", and then all the different programs that make use of those libraries, can access them. This would not require "root" privileges. If this were a work group pool, then it would only need "group" ones. If a private pool such as ${HOME}/m3work (the old WDROOT), I wouldn't need any special privileges. How would we specify the pool to which we desire to ship? Command line argument? --pool-install-path=${MYPROJECT}/m3pool -p ${MYPROJECT}/m3pool Environment Variable? M3_INSTALL_POOL=${MYPROJECT}/m3pool > >To satisfy package imports, the builder would start searching in the >first pool and continue until it has found an appropriate package. >This way local or project changes could easily be tested and integrated >before being `promoted' to a higher level. > >For backward compatibility reasons, there should be a default pool >(/usr/local/cm3) which is used when nothing else is defined. We could also make use of the paths built into M3Config, as part of the default search pool path. That is the reason that M3Config exists, so M3 programs can find at run-time the main installation pool, and its components (bin, lib, pkg, ..., etc). +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Mon Jul 6 22:17:03 2009 From: jay.krell at cornell.edu (Jay lastname) Date: Mon, 6 Jul 2009 20:17:03 +0000 Subject: [M3devel] WDROOT private repository not working? In-Reply-To: <67172.22662.qm@web56806.mail.re3.yahoo.com> References: <67172.22662.qm@web56806.mail.re3.yahoo.com> Message-ID: I think WDROOT was only ever a synonym for ROOT -- the root of the source tree, available for overrides to get "builtlocal" unshipped stuff. This does somewhat resemble what Olaf was talking about, but it is referencing, essentially, the source tree, in a different layout than the shipped tree. Instead Olaf and I advocate multiple (I think two is maybe enough) roots with the same layout as the shipped/installed system, instead of one shipped and one unshipped. All outputs that would be shipped should just go to this place, rather than first to build_dir and then later copied into the right layout. They might still be copied, but it would not be a layout changing copy. (And yes, this mechanism does work.) Searching for 'wdroot'... C:\dev2\cm3.2\m3-db\stable\example\src\m3makefile(7):override ("stable", WDROOT) % try to pick up the local copy C:\dev2\cm3.2\m3-libs\arithmetic\test\src\m3overrides(1):%override("arithmetic",WDROOT) C:\dev2\cm3.2\m3-libs\lapack\test\src\m3overrides(1):%override("lapack",WDROOT) C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(350):.BR WDROOT , C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(516):.B WDROOT C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(554):.B WDROOT C:\dev2\cm3.2\m3-sys\m3loader\src\m3makefile(10): override ("winlib", WDROOT) C:\dev2\cm3.2\m3-tools\m3tk\src\files\m3overrides.not(1):override(m3tk-misc.3.1, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(9):% override ("vbtkit", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(10):% override ("formsvbt", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(11):%override ("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(12):%override ("juno-compiler", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\src\m3overrides(10):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\compiler\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\compiler\src\m3overrides(10):%override("juno-compiler", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\lexer\src\m3overrides(9):override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\lexer\src\m3overrides(10):override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\parser\src\m3overrides(9):%override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\parser\src\m3overrides(10):%override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\scope\src\m3overrides(9):%override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\scope\src\m3overrides(10):%override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\linear\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\nonlinear\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\runtime\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\solve\src\m3overrides(3):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-www\http\src\m3makefile(7):%write("WDROOT = ", WDROOT, CR) 26 occurrence(s) have been found. - Jay > Date: Mon, 6 Jul 2009 10:00:19 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] WDROOT private repository not working? > > > Hi Guys, > > Seeing all the attention placed on creating relative > linking, and so forth, I decided to examine the behavior > of CM3, when building for a private root. > > So, I set WDROOT to ${HOME}/m3work in my m3makefile. > > ---- BEGIN m3makefile ---- > %# Time-Space-Position Information (TSPI) library > > HOME = "/home/peter" > WDROOT = HOME & "/m3work" > > include_dir("xform") > % include_dir("smoothing") > % include_dir("editing") > % include_dir("geoid") > % include_dir("testing") > ---- EMD m3makefile ---- > > > Then I, attempted to build and ship from there. > > It said, there was an error > > ---- BEGIN ERROR MSG ---- > peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship > --- shipping from ../AMD64_LINUX --- > > "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/usr/lib/cm3/pkg/tspi": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP > > ---- END ERROR MSG ---- > > > > Was support for WDROOT removed? Can CM3 support the ability to > have a private repository, while also having the public repo? > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 6 22:31:02 2009 From: jay.krell at cornell.edu (Jay lastname) Date: Mon, 6 Jul 2009 20:31:02 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <208085.23533.qm@web56807.mail.re3.yahoo.com> References: <208085.23533.qm@web56807.mail.re3.yahoo.com> Message-ID: Just fyi..I see this all maybe slightly differently. I'm not sure it works well beyond two pools. I'm not sure it works well with sparse pools -- particularly if $ORIGIN is used. Roughly I see it that there are two pools, ROOT/pkg and CM3_INSTALL/pkg. You build into ROOT/pkg and ship from ROOT/pkg to CM3_INSTALL/pkg. Ship, or promote, is possibly an entire pkg store to pkg store operation, not individual packages. If you remove the use of origin, then it might become easier to use multiple pools and sparse pool, however, imagine you build and ship a private m3core.so. Which programs and .so files are supposed to use that? If that is only the thing you build/ship, nothing will use it. Arguably that is correct, since nothing has been built against its possibly changed interfaces. Arguably all pools must be built up from the bottom of the dependency tree and on up. And the only allowed "sparseness" is that you don't "finish". This strikes at why you can't ship after buildlocal. That isn't the right restriction -- if you buildlocal "everything", then you have coherence and should be able to ship everything (but not selectively). However, now I painted ourselves into a perhaps less interesting corner and in fact the same place we already are -- you can always build up a new package store from scratch from the bottom of the dependency tree and on up. You can always put together a system as non-root. Now, let's consider if $ORIGIN is removed. In fact, by default we use $ORIGIN and full paths. Now you can have sparse or incomplete package stores but you have to be careful. I'm not sure how to formulate what the restrictions are, but for example, if you were to build and ship out of dependency order, you could end up with a system where multiple versions of the "same" .so files are in use, and it might or might not matter. You could have pkg1/m3core.so pkg1/libm3.so pkg2/m3core.so pkg2/libm3.so pkg2/libfoo.so pkg2/libbar.so libbar.so might depend on pkg1/libm3.so and pkg1/m3core.so and libfoo.so might depend on pkg2/libm3.so, pkg2/m3core.so. Depending on the order you built/shipped in. If libbar.so and libfoo.so never pass types to each other defined in m3core, then this is probably ok. However you might end up with multiple garbage collectors trying to free the same storage. I suggested that each package store be created by cloning the next one in the list. That helps address these situations. But "clone" vs. build from scratch from the bottom of the dependency tree and on up are, are similar. - Jay > Date: Mon, 6 Jul 2009 11:49:21 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 25 > > > Hi Olaf, > > > > Date: Fri, 03 Jul 2009 11:22:05 +0200 > > From: Olaf Wagner > > Subject: [M3devel] Some comments about package structure > > and package > > pools, was: > > Re: ROOT > > To: m3devel at elegosoft.com > > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com> > > Content-Type: text/plain; charset=ISO-8859-15; > > > >The CM3 builder needs to be extended to search a set of pools > >instead of just one (INSTALL_ROOT). This could be expressed by > >a CM3_POOL_PATH, similar to the Java class path: > > > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 > > Yes, I like it. I could then ship my data reduction > libraries to an appropriate "pool", and then all the > different programs that make use of those libraries, > can access them. This would not require "root" privileges. > If this were a work group pool, then it would only need > "group" ones. If a private pool such as ${HOME}/m3work > (the old WDROOT), I wouldn't need any special privileges. > > How would we specify the pool to which we desire to ship? > Command line argument? > > --pool-install-path=${MYPROJECT}/m3pool > -p ${MYPROJECT}/m3pool > > Environment Variable? > M3_INSTALL_POOL=${MYPROJECT}/m3pool > > > > > >To satisfy package imports, the builder would start searching in the > >first pool and continue until it has found an appropriate package. > >This way local or project changes could easily be tested and integrated > >before being `promoted' to a higher level. > > > >For backward compatibility reasons, there should be a default pool > >(/usr/local/cm3) which is used when nothing else is defined. > > We could also make use of the paths built into M3Config, > as part of the default search pool path. That is the > reason that M3Config exists, so M3 programs can find at > run-time the main installation pool, and its components > (bin, lib, pkg, ..., etc). > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Tue Jul 7 02:49:36 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Mon, 6 Jul 2009 20:49:36 -0400 Subject: [M3devel] multiple pkg roots In-Reply-To: References: <208085.23533.qm@web56807.mail.re3.yahoo.com> Message-ID: <4A526360.1E75.00D7.1@scires.com> >From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose. The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--ie. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight. Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose. Perhaps my understanding of what is meant by "pool" needs clarification? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Tue Jul 7 06:49:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 04:49:19 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <4A526360.1E75.00D7.1@scires.com> References: <208085.23533.qm@web56807.mail.re3.yahoo.com> <4A526360.1E75.00D7.1@scires.com> Message-ID: I believe these two things are highly related. When you have a multiple pool environment, you must be careful what you replace and in what order. Otherwise you end up with inconsistencies. As well, you possibly need a "runpath" that includes every pool -- i.e. you can't use $ORIGIN, you maybe can, maybe should not use full paths in runpath, probably using an LD_LIBRARY_PATH that shadows the pool list is what people expect. OR, what I described: you don't have any incomplete pools. Every "earlier" pool is initially a copy of any later pool. But then, you don't need any "list" of pools, you just need to create new pools, such as by copying or linking with copy-on-write from an existing pool. I still think there is something to be done here however. I think the initial unshipped output should be in the same or more similar directory structure as a shipped pool/package store/repository. For the outputs -- the .so, .m3x, .m3web, .m3exports files, this seems simple and good. The fact that shipping also copies all the source files however, is a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" placed upon output, then ship would just be a recursive copy, or move, or change the root. However "ship" remains "complicated" due to the "need" to ship the sources -- or, do sources not really need to be shipped? One thing I wonder, haven't tracked down, is if sources are shipped because the compiler, i.e. import, needs them, or "only" for debugging? Maybe the .m3x files handle all the import needs, and the .i3 files are never reparsed? Still, surely the source .ig files are shipped because they might be needed. And "only" for debugging is still important. Perhaps perhaps the source should be "shipped" as part of building? You know, they have to be read anyway, so it is not a super wasteful expense. You know, imagine I am in a long edit/compile/test loop, and won't really "ship" till much later -- is it a big waste for "compile" to also copy any changed files to the output directory, even though ultimately they are all dead except for the last version? I use Reactor briefly years ago, the commercial version. I was not impressed. As I recall it claims to be an "IDE", but lacks an editor and debugger, and maybe more. As I recall it is a custom web server, that you use with any browser, and provides not much more than browsing hyperlinked source code. I will try it again soon. Not providing an editor, in retrospect, is probably smart. I was young then and would have tried whatever ideal language oriented editor it came with. Since then I have used the same editor for over 10 years and reasons to change must be /extremely/ strong. Not providing a debugger was also probably not a bad decision, given the effort and system-specific work involved, though maybe a gui wrapper over gdb would be good (e.g. Xcode). - Jay ________________________________ > Date: Mon, 6 Jul 2009 20:49:36 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiple pkg roots > > > > > > > > From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose. > > > > The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--i.e. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers. > > > > Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight. > > > > Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose. > > > > Perhaps my understanding of what is meant by "pool" needs clarification? > > > > Regards, > > Randy Coleburn From wagner at elegosoft.com Tue Jul 7 08:26:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 08:26:23 +0200 Subject: [M3devel] WDROOT private repository not working? In-Reply-To: <67172.22662.qm@web56806.mail.re3.yahoo.com> References: <67172.22662.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090707082623.ihmzdg2lw8o8kook@mail.elegosoft.com> WDROOT has no special meaning in CM3, it was just a convention used in _some_ override files. More used just ROOT, so we left it that way years ago. The m3overrides mechanism does work as expected in CM3. If you speficy the -overrides option to the compiler, it additionally reads all m3override files. In almost all overrides shipped with CM3 ROOT is used. Hope this helps, Olaf Quoting Peter Eiserloh : > > Hi Guys, > > Seeing all the attention placed on creating relative > linking, and so forth, I decided to examine the behavior > of CM3, when building for a private root. > > So, I set WDROOT to ${HOME}/m3work in my m3makefile. > > ---- BEGIN m3makefile ---- > %# Time-Space-Position Information (TSPI) library > > HOME = "/home/peter" > WDROOT = HOME & "/m3work" > > include_dir("xform") > % include_dir("smoothing") > % include_dir("editing") > % include_dir("geoid") > % include_dir("testing") > ---- EMD m3makefile ---- > > > Then I, attempted to build and ship from there. > > It said, there was an error > > ---- BEGIN ERROR MSG ---- > peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship > --- shipping from ../AMD64_LINUX --- > > "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: > quake runtime error: unable to create directory > "/usr/lib/cm3/pkg/tspi": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP > > ---- END ERROR MSG ---- > > > > Was support for WDROOT removed? Can CM3 support the ability to > have a private repository, while also having the public repo? > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Tue Jul 7 08:54:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Jul 2009 23:54:58 -0700 Subject: [M3devel] multiple pkg roots In-Reply-To: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." Message-ID: <200907070654.n676swq8048959@taps.cs.caltech.edu> Jay K writes: > >a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla >ced upon output, then ship would just be a recursive copy, or move, or change >the root. However "ship" remains "complicated" due to the "need" to ship the s >ources -- or, do sources not really need to be shipped? One thing I wonder, ha >ven't tracked down, is if sources are shipped because the compiler, i.e. impor >t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im >port needs, and the .i3 files are never reparsed? Still, surely the source .ig > files are shipped because they might be needed. And "only" for debugging is s >till important. Perhaps perhaps the source should be "shipped" as part of buil >ding? You know, they have to be read anyway, so it is not a super wasteful exp >ense. You know, imagine I am in a long edit/compile/test loop, and won't reall >y "ship" till much later -- is it a big waste for "compile" to also copy any c >hanged files to the output directory, even though ultimately they are all dead > except for the last version? Isn't the main purpose of any programming language that it is used for human-to-human communication? The .i3s need to be shipped so that programmers can see the interface of the libraries they are using, whether it be for debugging or initial development. That also means they should be shipped precisely when the binaries are shipped (they have to remain synchronized). Things would get extremely confusing if sources (I'd prefer to call them "interfaces"---you don't have to ship the "implementation modules") and binaries are shipped at different times. Mika From jay.krell at cornell.edu Tue Jul 7 09:05:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 07:05:54 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <200907070654.n676swq8048959@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." <200907070654.n676swq8048959@taps.cs.caltech.edu> Message-ID: Mostly agreed. It's just, you know, there is a contradiction between "making ship just a recursive copy or link" and "not wastefully copying files" Given that files would only be copied when they change, and when they change they have to read anyway, maybe it's not so bad. The dilemna is whether or not "build" copies the sources, so that ship is just recursive copy/link, or if build shouldn't waste time doing so and ship would continue to do all/some directory layout changes. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 6 Jul 2009 23:54:58 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] multiple pkg roots > > Jay K writes: >> >>a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla >>ced upon output, then ship would just be a recursive copy, or move, or change >>the root. However "ship" remains "complicated" due to the "need" to ship the s >>ources -- or, do sources not really need to be shipped? One thing I wonder, ha >>ven't tracked down, is if sources are shipped because the compiler, i.e. impor >>t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im >>port needs, and the .i3 files are never reparsed? Still, surely the source .ig >> files are shipped because they might be needed. And "only" for debugging is s >>till important. Perhaps perhaps the source should be "shipped" as part of buil >>ding? You know, they have to be read anyway, so it is not a super wasteful exp >>ense. You know, imagine I am in a long edit/compile/test loop, and won't reall >>y "ship" till much later -- is it a big waste for "compile" to also copy any c >>hanged files to the output directory, even though ultimately they are all dead >> except for the last version? > > Isn't the main purpose of any programming language that it is used > for human-to-human communication? > > The .i3s need to be shipped so that programmers can see the interface > of the libraries they are using, whether it be for debugging or > initial development. That also means they should be shipped precisely > when the binaries are shipped (they have to remain synchronized). > Things would get extremely confusing if sources (I'd prefer to call > them "interfaces"---you don't have to ship the "implementation > modules") and binaries are shipped at different times. > > Mika From wagner at elegosoft.com Tue Jul 7 11:28:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 11:28:15 +0200 Subject: [M3devel] multiple pkg roots In-Reply-To: References: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." <200907070654.n676swq8048959@taps.cs.caltech.edu> Message-ID: <20090707112815.hn3o411jc4kc8ow4@mail.elegosoft.com> Just some short comments from me before I leave you again for a while: o My suggestion of using multiple pools is just a generalization of the existing PKGROOT concept. It's intended to better support project and team setups in software development. There was no intention to use this to support `CM3 evolution' as Randy calls it (though it could be used for it). o I would not like to restrict the concept to two pools or levels. o For a first step, I'd suggest to keep thing really simple: - make cm3 understand a CM3_POOL_PATH to satisfy imports - only ship to the leftmost pool in the path - mark the hierarchy level in the pools (e.g. 0: system global, 1: project level, 2: individual workspace level) - disallow shipping when packages from lower pools than the one shipped to are referenced This way, there is no explicit promote operation (that can be added later), but we should be able to keep the dependencies correct easily. (I haven't thought this through completely though, so I may be mistaken.) I just realize that this might not be correct though: if a library package is locally modified and tested in a local pool, we'd probably like the other importers in the global pool to use our new dependency, too, or we'd end up with two versions of the same library in our program, which would probably neither work (names clashes) nor be what we intended: so we'd have to teach cm3 to detect those `invalid' importers and forbid us to use them. I.e. modifying a base library would require us to recompile (and probably adapt) all depending packages. It seems that all this needs more and careful consideration... o I also strongly suggest to postpone all this until we've finished the current release. Olaf Quoting Jay K : > > Mostly agreed. > It's just, you know, there is a contradiction between > "making ship just a recursive copy or link" > and > "not wastefully copying files" > > > Given that files would only be copied when they change, and when > they change they have to read anyway, maybe it's not so bad. > > > The dilemna is whether or not "build" copies the sources, so that > ship is just recursive copy/link, or if build shouldn't waste time > doing so and ship would continue to do all/some directory layout > changes. > > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon, 6 Jul 2009 23:54:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] multiple pkg roots >> >> Jay K writes: >>> >>> a wrinkle. That is, if it were just the output .so, .m3x etc., >>> "correctly" pla >>> ced upon output, then ship would just be a recursive copy, or >>> move, or change >>> the root. However "ship" remains "complicated" due to the "need" >>> to ship the s >>> ources -- or, do sources not really need to be shipped? One thing >>> I wonder, ha >>> ven't tracked down, is if sources are shipped because the >>> compiler, i.e. impor >>> t, needs them, or "only" for debugging? Maybe the .m3x files >>> handle all the im >>> port needs, and the .i3 files are never reparsed? Still, surely >>> the source .ig >>> files are shipped because they might be needed. And "only" for >>> debugging is s >>> till important. Perhaps perhaps the source should be "shipped" as >>> part of buil >>> ding? You know, they have to be read anyway, so it is not a super >>> wasteful exp >>> ense. You know, imagine I am in a long edit/compile/test loop, and >>> won't reall >>> y "ship" till much later -- is it a big waste for "compile" to >>> also copy any c >>> hanged files to the output directory, even though ultimately they >>> are all dead >>> except for the last version? >> >> Isn't the main purpose of any programming language that it is used >> for human-to-human communication? >> >> The .i3s need to be shipped so that programmers can see the interface >> of the libraries they are using, whether it be for debugging or >> initial development. That also means they should be shipped precisely >> when the binaries are shipped (they have to remain synchronized). >> Things would get extremely confusing if sources (I'd prefer to call >> them "interfaces"---you don't have to ship the "implementation >> modules") and binaries are shipped at different times. >> >> Mika -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 7 14:31:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 12:31:13 +0000 Subject: [M3devel] pkg roots/origin/ld_library_path Message-ID: Really, I understand, but there is a problem nobody seems to see. Let's say there are multiple pkg roots. Remember my question? It is very important. "How are the dependencies of an .so or executable found?" What if I install to /opt/cm3. You install to $HOME/cm3 -- no need for root! We have some root/bin/executable. It uses of course libm3core.so. I want to be able to copy it from machine to machine, probably without relinking it or running some tool over it. People want to install libm3core.so to different places on different machines. Does root/bin/executable refer to /opt/cm3/lib? or $HOME/cm3/lib? or $ORIGIN/../lib? or no directory and user sets LD_LIBRARY_PATH? I'm not even sure you can omit the directory. There is a basic contradiction here. $ORIGIN is good. $ORIGIN is bad. LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. Full paths are good. Full paths are bad. The ability to install to different places is good. The ability to install to different places is bad. You cannot have all of: ability to specify install location AND multiple package roots, where a package root is sparse AND if I install to a custom location, I don't have to set LD_LIBRARY_PATH Now, while I advocate(d) $ORIGIN and custom install locations and no need for LD_LIBRARY_PATH, that approach does devolve to everything being in the same directory, which also seems not great. The difference is often that you don't use $ORIGIN for "well known important stuff". You don't get "libc.so" from $ORIGIN/../lib. You get it from where it always is, like /usr/lib or somesuch. You don't actually ever use a custom install for it. If you want to build your own, you are probably building your own entire system, and might use chroot as part of that. But where is the line between "my stuff" and "well known important stuff"? Where is the line between stuff that can be installed anywhere vs. stuff that must be installed to its "standard" location? - Jay From wagner at elegosoft.com Tue Jul 7 15:05:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 15:05:45 +0200 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: References: Message-ID: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> I understand that the $ORIGIN use in library paths does not work if we want to have hierarchical overrides for an arbitrary set of package pools. We'll either have to use absolute paths or rely on a correct (automatically computed?) LD_LIBRARY_PATH setting. How do $ORIGIN and LD_LIBRARY_PATH work together? Are there consistently defined semantics on different systems? Could we use $ORIGIN just for the one global system installation, and rely on absolute paths for all other pools? Of course we'd loose the ability to just copy from one pool to another this way, but that may not be that important. Anyway, we (at least I) won't work on it right now... Olaf Quoting Jay K : > > Really, I understand, but there is a problem nobody seems to see. > > > Let's say there are multiple pkg roots. > > > Remember my question? It is very important. > "How are the dependencies of an .so or executable found?" > > > What if I install to /opt/cm3. > You install to $HOME/cm3 -- no need for root! > We have some root/bin/executable. > It uses of course libm3core.so. > > > I want to be able to copy it from machine to machine, probably > without relinking it or running some tool over it. > > > People want to install libm3core.so to different places on different > machines. > > > Does root/bin/executable refer > to /opt/cm3/lib? > or $HOME/cm3/lib? > or $ORIGIN/../lib? > or no directory and user sets LD_LIBRARY_PATH? > I'm not even sure you can omit the directory. > > > There is a basic contradiction here. > $ORIGIN is good. $ORIGIN is bad. > LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. > Full paths are good. Full paths are bad. > The ability to install to different places is good. The ability to > install to different places is bad. > > > You cannot have all of: > ability to specify install location > AND multiple package roots, where a package root is sparse > AND if I install to a custom location, I don't have to set LD_LIBRARY_PATH > > > Now, while I advocate(d) $ORIGIN and custom install locations and no > need for LD_LIBRARY_PATH, that approach does devolve to everything > being in the same directory, which also seems not great. > > > The difference is often that you don't use $ORIGIN for "well known > important stuff". > You don't get "libc.so" from $ORIGIN/../lib. You get it from where > it always is, like /usr/lib or somesuch. You don't actually ever use > a custom install for it. If you want to build your own, you are > probably building your own entire system, and might use chroot as > part of that. > > > But where is the line between "my stuff" and "well known important > stuff"? Where is the line between stuff that can be installed > anywhere vs. stuff that must be installed to its "standard" location? > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Tue Jul 7 22:02:53 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Jul 2009 15:02:53 -0500 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <20090703231254.GA25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> Message-ID: <4A53A9ED.8020908@cox.net> This may only be peripherally related, but since this discussion has come up: I have long wished for a directory, neither src, nor the architecture directory, for files that are mechanically generated but not target dependent. I have an application where there are several machine-generated files containing Modula-3 "source" code. It's "source code", in the sense that it is input to the compiler, but not "source code", in the sense that it is not written by a human using an editor. Some existing quake commands for instantiating generics do similarly. Neither place is entirely appropriate for these files. I have gone through a series of kludgy ways of handling this. Right now, I have them in a directory "derived", beside "src", with lines in m3makefiles that look, e.g., like: 'implementation("../derived/M3InitTokStrings")'. But the instantiating quake functions put generated source code in the arch directory, and sometimes unnecessarily regenerate it. Just something that it would be nice to clean up. hendrik at topoi.pooq.com wrote: > It seems relevant to out multiarchitecture system that Debian and Ubuntu > are currently also struggling to put together a multiarchitecture > system. > > Current thinking seems to be posted at > https://wiki.ubuntu.com/MultiarchSpec > > The stimulus for this work seems to be having 32-bit and 64-bit programs > coexist on the same AMD-64 system. But it also deals with questions > like MIPS systems having at least three different ABIs. > > Have a look. > > -- hendrik > > > From mika at async.caltech.edu Tue Jul 7 23:16:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Jul 2009 14:16:00 -0700 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> Message-ID: <200907072116.n67LG01G054470@taps.cs.caltech.edu> Going in the "other direction" it might be nice to have different derived directories for different compilers, e.g., CM3 and PM3, or different versions of CM3. Not something that is really necessary for anyone, I'm sure, but it seems like a flexible mechanism for "derived" directories might be able to handle that too... Mika "Rodney M. Bates" writes: >This may only be peripherally related, but since this discussion >has come up: > >I have long wished for a directory, neither src, nor the architecture >directory, for files that are mechanically generated but not >target dependent. I have an application where there are several >machine-generated files containing Modula-3 "source" code. > >It's "source code", in the sense that it is input to the compiler, but not >"source code", in the sense that it is not written by a human using >an editor. Some existing quake commands for instantiating generics >do similarly. Neither place is entirely appropriate for these files. > >I have gone through a series of kludgy ways of handling this. Right >now, I have them in a directory "derived", beside "src", with lines in >m3makefiles that look, e.g., like: > 'implementation("../derived/M3InitTokStrings")'. > >But the instantiating quake functions put generated source code in >the arch directory, and sometimes unnecessarily regenerate it. > >Just something that it would be nice to clean up. > >hendrik at topoi.pooq.com wrote: >> It seems relevant to out multiarchitecture system that Debian and Ubuntu >> are currently also struggling to put together a multiarchitecture >> system. >> >> Current thinking seems to be posted at >> https://wiki.ubuntu.com/MultiarchSpec >> >> The stimulus for this work seems to be having 32-bit and 64-bit programs >> coexist on the same AMD-64 system. But it also deals with questions >> like MIPS systems having at least three different ABIs. >> >> Have a look. >> >> -- hendrik >> >> >> From jay.krell at cornell.edu Tue Jul 7 23:48:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 21:48:47 +0000 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <200907072116.n67LG01G054470@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> <200907072116.n67LG01G054470@taps.cs.caltech.edu> Message-ID: Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are. The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages. So you could do export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here ./do-cm3-std.py buildship export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here ./do-cm3-std.py buildship etc. ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there. The "problem" is that compile/link don't. Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path. MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line. Then you'd just export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic. However you get stuck in the "what is the same? What is different?" dilemna. What if I want to not optimize just some particular code I am debugging? It should still go along with all the rest of the code. What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto. Probably the "hash" overridable from the command line. But you still want good defaults. I have not seen this automatic approach used much. But certainly the idea of one output root is good. Certainly the original authors were thinking this way, they just stopped way short. - Jay ---------------------------------------- > To: rodney.m.bates at cox.net > Date: Tue, 7 Jul 2009 14:16:00 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch) > > Going in the "other direction" it might be nice to have different > derived directories for different compilers, e.g., CM3 and PM3, or > different versions of CM3. > > Not something that is really necessary for anyone, I'm sure, but > it seems like a flexible mechanism for "derived" directories might > be able to handle that too... > > Mika > > "Rodney M. Bates" writes: >>This may only be peripherally related, but since this discussion >>has come up: >> >>I have long wished for a directory, neither src, nor the architecture >>directory, for files that are mechanically generated but not >>target dependent. I have an application where there are several >>machine-generated files containing Modula-3 "source" code. >> >>It's "source code", in the sense that it is input to the compiler, but not >>"source code", in the sense that it is not written by a human using >>an editor. Some existing quake commands for instantiating generics >>do similarly. Neither place is entirely appropriate for these files. >> >>I have gone through a series of kludgy ways of handling this. Right >>now, I have them in a directory "derived", beside "src", with lines in >>m3makefiles that look, e.g., like: >> 'implementation("../derived/M3InitTokStrings")'. >> >>But the instantiating quake functions put generated source code in >>the arch directory, and sometimes unnecessarily regenerate it. >> >>Just something that it would be nice to clean up. >> >>hendrik at topoi.pooq.com wrote: >>> It seems relevant to out multiarchitecture system that Debian and Ubuntu >>> are currently also struggling to put together a multiarchitecture >>> system. >>> >>> Current thinking seems to be posted at >>> https://wiki.ubuntu.com/MultiarchSpec >>> >>> The stimulus for this work seems to be having 32-bit and 64-bit programs >>> coexist on the same AMD-64 system. But it also deals with questions >>> like MIPS systems having at least three different ABIs. >>> >>> Have a look. >>> >>> -- hendrik >>> >>> >>> From jay.krell at cornell.edu Tue Jul 7 22:56:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 7 Jul 2009 13:56:05 -0700 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> Message-ID: I see the base contradiction is between custom install location, non root install, and Unix binary installs. Whenever I install binaries in Unix I have to be root and I get no choice of install location. Only when I build from source are both of these relaxed. Windows varies. Often I can chose install location and sometimes I don't have to be admin (but I always am). $origin is a way to address this, but relative locations remain fixed. - Jay (phone) On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: > I understand that the $ORIGIN use in library paths does not work > if we want to have hierarchical overrides for an arbitrary set of > package pools. We'll either have to use absolute paths or rely > on a correct (automatically computed?) LD_LIBRARY_PATH setting. > > How do $ORIGIN and LD_LIBRARY_PATH work together? Are there > consistently defined semantics on different systems? > > Could we use $ORIGIN just for the one global system installation, > and rely on absolute paths for all other pools? Of course we'd > loose the ability to just copy from one pool to another this way, > but that may not be that important. > > Anyway, we (at least I) won't work on it right now... > > Olaf > > Quoting Jay K : > >> >> Really, I understand, but there is a problem nobody seems to see. >> >> >> Let's say there are multiple pkg roots. >> >> >> Remember my question? It is very important. >> "How are the dependencies of an .so or executable found?" >> >> >> What if I install to /opt/cm3. >> You install to $HOME/cm3 -- no need for root! >> We have some root/bin/executable. >> It uses of course libm3core.so. >> >> >> I want to be able to copy it from machine to machine, probably >> without relinking it or running some tool over it. >> >> >> People want to install libm3core.so to different places on >> different machines. >> >> >> Does root/bin/executable refer >> to /opt/cm3/lib? >> or $HOME/cm3/lib? >> or $ORIGIN/../lib? >> or no directory and user sets LD_LIBRARY_PATH? >> I'm not even sure you can omit the directory. >> >> >> There is a basic contradiction here. >> $ORIGIN is good. $ORIGIN is bad. >> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >> Full paths are good. Full paths are bad. >> The ability to install to different places is good. The ability to >> install to different places is bad. >> >> >> You cannot have all of: >> ability to specify install location >> AND multiple package roots, where a package root is sparse >> AND if I install to a custom location, I don't have to set >> LD_LIBRARY_PATH >> >> >> Now, while I advocate(d) $ORIGIN and custom install locations and >> no need for LD_LIBRARY_PATH, that approach does devolve to >> everything being in the same directory, which also seems not great. >> >> >> The difference is often that you don't use $ORIGIN for "well known >> important stuff". >> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >> it always is, like /usr/lib or somesuch. You don't actually ever >> use a custom install for it. If you want to build your own, you >> are probably building your own entire system, and might use chroot >> as part of that. >> >> >> But where is the line between "my stuff" and "well known important >> stuff"? Where is the line between stuff that can be installed >> anywhere vs. stuff that must be installed to its "standard" location? >> >> >> - Jay > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Tue Jul 7 23:50:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 21:50:05 +0000 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <200907072116.n67LG01G054470@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> <200907072116.n67LG01G054470@taps.cs.caltech.edu> Message-ID: ps: ccache is something that kind of goes this automatic way, but for different reasons and not really applicable. It is looking for opportunistic identicalness and really striving for the strongest definition of identical. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; rodney.m.bates at cox.net > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Arch-independent derived files (Re: multiarch) > Date: Tue, 7 Jul 2009 21:48:47 +0000 > > > Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are. > > > The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages. > > > So you could do > > export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here > export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here > ./do-cm3-std.py buildship > > > export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here > export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here > ./do-cm3-std.py buildship > > etc. > > ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there. > > The "problem" is that compile/link don't. > > Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path. > > MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line. > > Then you'd just > export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic. > > However you get stuck in the "what is the same? What is different?" dilemna. > What if I want to not optimize just some particular code I am debugging? > It should still go along with all the rest of the code. > What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto. > > > Probably the "hash" overridable from the command line. > But you still want good defaults. > > > I have not seen this automatic approach used much. > But certainly the idea of one output root is good. > Certainly the original authors were thinking this way, they just stopped way short. > > > - Jay > > > > > > ---------------------------------------- >> To: rodney.m.bates at cox.net >> Date: Tue, 7 Jul 2009 14:16:00 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch) >> >> Going in the "other direction" it might be nice to have different >> derived directories for different compilers, e.g., CM3 and PM3, or >> different versions of CM3. >> >> Not something that is really necessary for anyone, I'm sure, but >> it seems like a flexible mechanism for "derived" directories might >> be able to handle that too... >> >> Mika >> >> "Rodney M. Bates" writes: >>>This may only be peripherally related, but since this discussion >>>has come up: >>> >>>I have long wished for a directory, neither src, nor the architecture >>>directory, for files that are mechanically generated but not >>>target dependent. I have an application where there are several >>>machine-generated files containing Modula-3 "source" code. >>> >>>It's "source code", in the sense that it is input to the compiler, but not >>>"source code", in the sense that it is not written by a human using >>>an editor. Some existing quake commands for instantiating generics >>>do similarly. Neither place is entirely appropriate for these files. >>> >>>I have gone through a series of kludgy ways of handling this. Right >>>now, I have them in a directory "derived", beside "src", with lines in >>>m3makefiles that look, e.g., like: >>> 'implementation("../derived/M3InitTokStrings")'. >>> >>>But the instantiating quake functions put generated source code in >>>the arch directory, and sometimes unnecessarily regenerate it. >>> >>>Just something that it would be nice to clean up. >>> >>>hendrik at topoi.pooq.com wrote: >>>> It seems relevant to out multiarchitecture system that Debian and Ubuntu >>>> are currently also struggling to put together a multiarchitecture >>>> system. >>>> >>>> Current thinking seems to be posted at >>>> https://wiki.ubuntu.com/MultiarchSpec >>>> >>>> The stimulus for this work seems to be having 32-bit and 64-bit programs >>>> coexist on the same AMD-64 system. But it also deals with questions >>>> like MIPS systems having at least three different ABIs. >>>> >>>> Have a look. >>>> >>>> -- hendrik >>>> >>>> >>>> From jay.krell at cornell.edu Tue Jul 7 22:38:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 7 Jul 2009 13:38:48 -0700 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <4A53A9ED.8020908@cox.net> References: <20090703231254.GA25415@topoi.pooq.com> <4A53A9ED.8020908@cox.net> Message-ID: I have seen systems head that way, only to abandon it, for the sake of consistency and simplicity -- outputs all in one more known place, and for concurrency -- build multiple architectures without them stomping on each other. Are the files large or slow to be generated? I am on the fence. I like identifying what is the same and removing duplication. But if it is automated and fast, less motivation. Considering more of the system, we do parse identical .i3 files per- platform. The middle end work is also almost the same for every platform. But judging from the overall NT386 speed, this is all very fast. - Jay (phone) On Jul 7, 2009, at 1:02 PM, "Rodney M. Bates" wrote: > This may only be peripherally related, but since this discussion > has come up: > > I have long wished for a directory, neither src, nor the architecture > directory, for files that are mechanically generated but not > target dependent. I have an application where there are several > machine-generated files containing Modula-3 "source" code. > > It's "source code", in the sense that it is input to the compiler, > but not > "source code", in the sense that it is not written by a human using > an editor. Some existing quake commands for instantiating generics > do similarly. Neither place is entirely appropriate for these files. > > I have gone through a series of kludgy ways of handling this. Right > now, I have them in a directory "derived", beside "src", with lines in > m3makefiles that look, e.g., like: > 'implementation("../derived/M3InitTokStrings")'. > > But the instantiating quake functions put generated source code in > the arch directory, and sometimes unnecessarily regenerate it. > > Just something that it would be nice to clean up. > > hendrik at topoi.pooq.com wrote: >> It seems relevant to out multiarchitecture system that Debian and >> Ubuntu are currently also struggling to put together a >> multiarchitecture system. >> >> Current thinking seems to be posted at >> https://wiki.ubuntu.com/MultiarchSpec >> >> The stimulus for this work seems to be having 32-bit and 64-bit >> programs coexist on the same AMD-64 system. But it also deals with >> questions like MIPS systems having at least three different ABIs. >> >> Have a look. >> >> -- hendrik >> >> >> > > From carson at taltos.org Fri Jul 10 01:15:51 2009 From: carson at taltos.org (Carson Gaspar) Date: Thu, 09 Jul 2009 16:15:51 -0700 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> Message-ID: <4A567A27.8080203@taltos.org> LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X) _usually_ overrides a compiled-in search path. I know it does on Linux, MacOS X, and Solaris. And yes, you can "omit the directory" on most flavours of UNIX (although not on MacOS X, which gets complicated). If you leave out rpath, only the system default locations (and LD_LIBRARY_PATH, if set) will be searched. My opinion: - The primary installation should be built using a relative RPATH only ($ORIGIN/../lib or whatever). That does imply flatening the installed namespace to something more traditional, or including symlinks (if you have /usr/local/m3/lib/libfoo.so and /usr/local/m3/my/sub/module/mybinary you'd need to symlink /usr/local/m3/my/sub/module/lib to ../../../lib, or symlink each .so.*). - If a user builds with an alternate root, it should include an absolute RPATH for the standard installed location. It may _also_ include a relative RPATH, if needed (module builds its own .so libs), which should come first. This allows: - The binary install to be moved between systems easily - Binary non-standard location modules to be moved to any location on systems that share the same standard install location. This is about as flexible as you can get on most platforms. Note that on MacOS X you can use install_name_tool to re-write library locations, as long as the original was built with enough padding (linked with -headerpad_max_install_names, or the new name is shorter). This will also be possible on newer versions of Solaris, but is not yet in Sol 10 (only in OpenSolaris). jay.krell at cornell.edu wrote: > I see the base contradiction is between custom install location, non > root install, and Unix binary installs. Whenever I install binaries in > Unix I have to be root and I get no choice of install location. Only > when I build from source are both of these relaxed. > > Windows varies. Often I can chose install location and sometimes I don't > have to be admin (but I always am). > > $origin is a way to address this, but relative locations remain fixed. > > - Jay (phone) > > On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: > >> I understand that the $ORIGIN use in library paths does not work >> if we want to have hierarchical overrides for an arbitrary set of >> package pools. We'll either have to use absolute paths or rely >> on a correct (automatically computed?) LD_LIBRARY_PATH setting. >> >> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there >> consistently defined semantics on different systems? >> >> Could we use $ORIGIN just for the one global system installation, >> and rely on absolute paths for all other pools? Of course we'd >> loose the ability to just copy from one pool to another this way, >> but that may not be that important. >> >> Anyway, we (at least I) won't work on it right now... >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Really, I understand, but there is a problem nobody seems to see. >>> >>> >>> Let's say there are multiple pkg roots. >>> >>> >>> Remember my question? It is very important. >>> "How are the dependencies of an .so or executable found?" >>> >>> >>> What if I install to /opt/cm3. >>> You install to $HOME/cm3 -- no need for root! >>> We have some root/bin/executable. >>> It uses of course libm3core.so. >>> >>> >>> I want to be able to copy it from machine to machine, probably >>> without relinking it or running some tool over it. >>> >>> >>> People want to install libm3core.so to different places on different >>> machines. >>> >>> >>> Does root/bin/executable refer >>> to /opt/cm3/lib? >>> or $HOME/cm3/lib? >>> or $ORIGIN/../lib? >>> or no directory and user sets LD_LIBRARY_PATH? >>> I'm not even sure you can omit the directory. >>> >>> >>> There is a basic contradiction here. >>> $ORIGIN is good. $ORIGIN is bad. >>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >>> Full paths are good. Full paths are bad. >>> The ability to install to different places is good. The ability to >>> install to different places is bad. >>> >>> >>> You cannot have all of: >>> ability to specify install location >>> AND multiple package roots, where a package root is sparse >>> AND if I install to a custom location, I don't have to set >>> LD_LIBRARY_PATH >>> >>> >>> Now, while I advocate(d) $ORIGIN and custom install locations and no >>> need for LD_LIBRARY_PATH, that approach does devolve to everything >>> being in the same directory, which also seems not great. >>> >>> >>> The difference is often that you don't use $ORIGIN for "well known >>> important stuff". >>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >>> it always is, like /usr/lib or somesuch. You don't actually ever use >>> a custom install for it. If you want to build your own, you are >>> probably building your own entire system, and might use chroot as >>> part of that. >>> >>> >>> But where is the line between "my stuff" and "well known important >>> stuff"? Where is the line between stuff that can be installed >>> anywhere vs. stuff that must be installed to its "standard" location? >>> >>> >>> - Jay >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 >> 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> From jay.krell at cornell.edu Fri Jul 10 03:36:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 10 Jul 2009 01:36:21 +0000 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: <4A567A27.8080203@taltos.org> References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> <4A567A27.8080203@taltos.org> Message-ID: I think we very much agree. Which comes first, LD_LIBRARY_PATH or runpath? The default build uses both $ORIGIN/../lib and fullpath. Like you suggest. I forget the order. $ORIGIN first would be good I think. I'll check and make it so. There is an environment variable to suppress the fullpath. The existing "scripts" set it. You can find its name in the scripts and the config files. Something like CM3_PORTABLE_RUNPATH. I know environment variables are lame. The structure has already been flattened. It was always "available" flattened, but symlinked into the deep structure, which I believe largely defeated our current goals. Now there is just the flat structure and the deep structure is "gone" (well, two files removed out of each directory). I also put $ORIGIN alone in the runpath, without the ../lib, so you can further flatten lib into bin. I'm fairly sympathetic to that but I suspect not many other people are. ? I always reserve the maximum space on MacOSX (in the config files), having seen that stuff in the manpages and figuring "reserving the maximum" probably isn't too wasteful and is a nice item on the "flexibility checklist" (that is, something I'll probably never use, but if anyone wants it, sure, it's there). That way, "link upon install" can be "run that tool upon install". I had seen similar for Solaris but I forget the details, which you filled in. - Jay ---------------------------------------- > Date: Thu, 9 Jul 2009 16:15:51 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] pkg roots/origin/ld_library_path > > LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X) _usually_ overrides a > compiled-in search path. I know it does on Linux, MacOS X, and Solaris. > > And yes, you can "omit the directory" on most flavours of UNIX (although not on > MacOS X, which gets complicated). If you leave out rpath, only the system > default locations (and LD_LIBRARY_PATH, if set) will be searched. > > My opinion: > > - The primary installation should be built using a relative RPATH only > ($ORIGIN/../lib or whatever). That does imply flatening the installed namespace > to something more traditional, or including symlinks (if you have > /usr/local/m3/lib/libfoo.so and /usr/local/m3/my/sub/module/mybinary you'd need > to symlink /usr/local/m3/my/sub/module/lib to ../../../lib, or symlink each .so.*). > > - If a user builds with an alternate root, it should include an absolute RPATH > for the standard installed location. It may _also_ include a relative RPATH, if > needed (module builds its own .so libs), which should come first. > > This allows: > > - The binary install to be moved between systems easily > - Binary non-standard location modules to be moved to any location on systems > that share the same standard install location. > > This is about as flexible as you can get on most platforms. > > Note that on MacOS X you can use install_name_tool to re-write library > locations, as long as the original was built with enough padding (linked with > -headerpad_max_install_names, or the new name is shorter). This will also be > possible on newer versions of Solaris, but is not yet in Sol 10 (only in > OpenSolaris). > > > jay.krell at cornell.edu wrote: >> I see the base contradiction is between custom install location, non >> root install, and Unix binary installs. Whenever I install binaries in >> Unix I have to be root and I get no choice of install location. Only >> when I build from source are both of these relaxed. >> >> Windows varies. Often I can chose install location and sometimes I don't >> have to be admin (but I always am). >> >> $origin is a way to address this, but relative locations remain fixed. >> >> - Jay (phone) >> >> On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: >> >>> I understand that the $ORIGIN use in library paths does not work >>> if we want to have hierarchical overrides for an arbitrary set of >>> package pools. We'll either have to use absolute paths or rely >>> on a correct (automatically computed?) LD_LIBRARY_PATH setting. >>> >>> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there >>> consistently defined semantics on different systems? >>> >>> Could we use $ORIGIN just for the one global system installation, >>> and rely on absolute paths for all other pools? Of course we'd >>> loose the ability to just copy from one pool to another this way, >>> but that may not be that important. >>> >>> Anyway, we (at least I) won't work on it right now... >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Really, I understand, but there is a problem nobody seems to see. >>>> >>>> >>>> Let's say there are multiple pkg roots. >>>> >>>> >>>> Remember my question? It is very important. >>>> "How are the dependencies of an .so or executable found?" >>>> >>>> >>>> What if I install to /opt/cm3. >>>> You install to $HOME/cm3 -- no need for root! >>>> We have some root/bin/executable. >>>> It uses of course libm3core.so. >>>> >>>> >>>> I want to be able to copy it from machine to machine, probably >>>> without relinking it or running some tool over it. >>>> >>>> >>>> People want to install libm3core.so to different places on different >>>> machines. >>>> >>>> >>>> Does root/bin/executable refer >>>> to /opt/cm3/lib? >>>> or $HOME/cm3/lib? >>>> or $ORIGIN/../lib? >>>> or no directory and user sets LD_LIBRARY_PATH? >>>> I'm not even sure you can omit the directory. >>>> >>>> >>>> There is a basic contradiction here. >>>> $ORIGIN is good. $ORIGIN is bad. >>>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >>>> Full paths are good. Full paths are bad. >>>> The ability to install to different places is good. The ability to >>>> install to different places is bad. >>>> >>>> >>>> You cannot have all of: >>>> ability to specify install location >>>> AND multiple package roots, where a package root is sparse >>>> AND if I install to a custom location, I don't have to set >>>> LD_LIBRARY_PATH >>>> >>>> >>>> Now, while I advocate(d) $ORIGIN and custom install locations and no >>>> need for LD_LIBRARY_PATH, that approach does devolve to everything >>>> being in the same directory, which also seems not great. >>>> >>>> >>>> The difference is often that you don't use $ORIGIN for "well known >>>> important stuff". >>>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >>>> it always is, like /usr/lib or somesuch. You don't actually ever use >>>> a custom install for it. If you want to build your own, you are >>>> probably building your own entire system, and might use chroot as >>>> part of that. >>>> >>>> >>>> But where is the line between "my stuff" and "well known important >>>> stuff"? Where is the line between stuff that can be installed >>>> anywhere vs. stuff that must be installed to its "standard" location? >>>> >>>> >>>> - Jay >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 >>> 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> > > From wagner at elegosoft.com Sat Jul 11 12:47:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Jul 2009 12:47:44 +0200 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <255528.11130.qm@web56801.mail.re3.yahoo.com> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Hm, I'm afraid we may have a regression in the runtime/gc here. CVSup always worked without problems for me (and still is copying FreeBSD, CM3 and other repositories between various machines for me and Elego). Surely CVSup is doing no such thing as keeping all its files in memory. I haven't tried the version Jay put into the CM3 repo though. So I see three possibilities: o Jay introduced the problem in the CVSup sources when he adapted them to the current CM3 (low probability). o You've got a broken runtime / CM3 version (and current sources work). I'd guess you are using the current version though. o We've got a problem in our runtime code, perhaps -- but not necessarily -- the garbage collector. I'd suggest we rule out the second one and you reproduce the problem with a current source set (if not done yet). Then let's see what Jay and Antony have to say, as they did almost all the source changes in that area recently. Olaf Quoting Peter Eiserloh : > Hi Olaf, > > Well, I tried CVSup, and it started looking real good, until > it crashed, with a message from the M3 runtime, saying that > NEW could not allocate any memory. > > So I ran it a second time, and it got further, then crashed > again. > > So, a third time, but with "top" running in another window, > and sure enough cvsup, was allocating something like 1.2 GB > of data before it was crashing. This is bigger than the > CVS repository that it had already downloaded. > > I am thinking that cvsup is keeping the contents of every > file it downloaded in memory. If so, this is a problem. > > If it is properly removing references, then maybe the > garbage collector is failing. This would be a bigger > problem, but with our compiler's runtime library. > > Are other people noticing problems. Is it just me? > Am I the only one to attempt downloading the entire > CVS repository for CM3? Could you try it? > > > I sent an email to the email listed in cvsup's "about box" > (cvsup-bugs at polstra.com), but that failed. The email address > no longer works. > > peter at black:/data/modula-3/cm3 $ > debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup cvsupfile.cm3 > > *** > *** runtime error: > *** NEW() was unable to allocate more memory. > *** file "../src/runtime/common/RuntimeError.m3", line 63 > *** > > Aborted > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Olaf Wagner wrote: > >> From: Olaf Wagner >> Subject: Re: m3gdb and YACC >> To: "Peter Eiserloh" >> Date: Saturday, July 11, 2009, 2:49 AM >> Quoting Peter Eiserloh : >> >> > Hi Olaf, >> > >> > The import script (git-importcvs) internally uses >> cvsps, which >> > you may already have. >> > >> > Anyways, here is the first ten lines from a log file >> of an import >> > that I just started. >> > >> > >> > peter at black:~ $ head Import-cm3-20090708.log >> > Running cvsps... >> > WARNING: revision 1.1.3.1 of file >> m3-sys/m3cc/gcc/etc/make-stds.texi? on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >> > WARNING: revision 1.1.3.1 of file >> m3-sys/m3cc/gcc/.brik on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >> branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >> branch >> >> It looks like these files have a second vendor branch >> without a >> proper name. CVS does not cope well with multiple vendor >> branches >> (in fact it never really worked), but there won't be any >> valuable >> information in that branch I'm sure, so you can ignore it. >> >> > Later this weekend, I will attempt to use CVSup.? >> First, >> > I will have to find usable documentation, since I >> have >> > never used CVSup before. >> > >> > Do you have a script to use with CVSup to access the >> > CM3 CVS repo?? I am lasy. >> > >> > I use 'git' for all my current projects.? I used >> to use >> > CVS, and had started looking into using subversion >> (SVN), >> > I even purchased a couple books on SVN.? Then >> 'git' burst >> > upon the Linux world, and is gaining converts all over >> the >> > place. >> > >> > It really does provide a better work-flow.? The >> easy >> > creation of a branch is a given, it is git's ability >> > to do easy merges, which is gaining all the good >> reputation. >> > >> > Rather than get all evangelistic on you, as I am sure >> you >> > have already heard it many times already. >> > >> > Many businesses are moving to git.? The only >> problem some >> > enterprise companies are having is the ability to >> restrict >> > access of authorized users to only portions of the >> repository. >> > These types of problems don't effect open source >> software >> > development. >> > >> > Once I have a working 'git' repository for cm3, I will >> share >> > the technique, and maybe, start the foundations for a >> > transition from CVS, towards 'git'.? But I >> suggest a slow >> > process, with distinct stages.???At any >> stage we could stop, >> > or even revert. >> > >> > The problem is that once people start using git, they >> don''t >> > want to go back to using CVS, or any of the older >> methods. >> > Maybe that isn't so much of a problem after all. >> > >> > STAGE-1: Simple mirror of the CVS archive, >> periodically >> >? ? ? ? ? updated (say once >> every 6 hours).? Document on >> >? ? ? ? ? web site, as to how >> to clone, and update a git >> >? ? ? ? ? repository.? No >> uploads to git. >> > STAGE-2: Convert web page scripts to use git. >> > STAGE-3: Convert tinderbox. >> > STAGE-4: Uploads to git.? Install gitosis or >> similar server >> >? ? ? ? ? for git uploads. >> Document the upload process on web >> >? ? ? ? ? pages. >> > STAGE-5: CVS mirrors the git repo.? Uploads to >> git only. >> > STAGE-6: Move last of the CVS people, over to git. >> > STAGE-7: Remove CVS.? (optional) >> >> Let's see how far you get. Converting all the >> infrastructure (scripts >> and documentation) may be much more work than you imagine. >> And one >> we propose a special tool (be it git or svn or mercurial) >> there will >> start discussions on what is best and what we should do >> :-/ >> >> So offering an optional alternative access may be a good >> plan. >> The majority of users should agree that they want the >> change though. >> And we need to consider use of GUIs and Windows users, >> too. >> >> Olaf >> --Olaf Wagner -- elego Software Solutions GmbH >> ? ? ? ? ? ? >> ???Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, Germany >> phone: +49 30 23 45 86 96? mobile: +49 177 2345 >> 869? fax: +49 30 23 45 86 95 >> ???http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 11 17:19:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 11:19:52 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: I'd definitely need some way to reproduce the problem. Detailed instructions would be best. What platform are you running on? On 11 Jul 2009, at 06:47, Olaf Wagner wrote: > Hm, I'm afraid we may have a regression in the runtime/gc here. > CVSup always worked without problems for me (and still is copying > FreeBSD, CM3 and other repositories between various machines for > me and Elego). Surely CVSup is doing no such thing as keeping > all its files in memory. > > I haven't tried the version Jay put into the CM3 repo though. > So I see three possibilities: > > o Jay introduced the problem in the CVSup sources when he > adapted them to the current CM3 (low probability). > > o You've got a broken runtime / CM3 version (and current > sources work). I'd guess you are using the current version though. > > o We've got a problem in our runtime code, perhaps -- but not > necessarily -- the garbage collector. > > I'd suggest we rule out the second one and you reproduce the problem > with a current source set (if not done yet). Then let's see what Jay > and Antony have to say, as they did almost all the source changes > in that area recently. > > Olaf > > Quoting Peter Eiserloh : > >> Hi Olaf, >> >> Well, I tried CVSup, and it started looking real good, until >> it crashed, with a message from the M3 runtime, saying that >> NEW could not allocate any memory. >> >> So I ran it a second time, and it got further, then crashed >> again. >> >> So, a third time, but with "top" running in another window, >> and sure enough cvsup, was allocating something like 1.2 GB >> of data before it was crashing. This is bigger than the >> CVS repository that it had already downloaded. >> >> I am thinking that cvsup is keeping the contents of every >> file it downloaded in memory. If so, this is a problem. >> >> If it is properly removing references, then maybe the >> garbage collector is failing. This would be a bigger >> problem, but with our compiler's runtime library. >> >> Are other people noticing problems. Is it just me? >> Am I the only one to attempt downloading the entire >> CVS repository for CM3? Could you try it? >> >> >> I sent an email to the email listed in cvsup's "about box" >> (cvsup-bugs at polstra.com), but that failed. The email address >> no longer works. >> >> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/usr/ >> lib/cm3/bin/cvsup cvsupfile.cm3 >> >> *** >> *** runtime error: >> *** NEW() was unable to allocate more memory. >> *** file "../src/runtime/common/RuntimeError.m3", line 63 >> *** >> >> Aborted >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, Olaf Wagner wrote: >> >>> From: Olaf Wagner >>> Subject: Re: m3gdb and YACC >>> To: "Peter Eiserloh" >>> Date: Saturday, July 11, 2009, 2:49 AM >>> Quoting Peter Eiserloh : >>> >>> > Hi Olaf, >>> > >>> > The import script (git-importcvs) internally uses >>> cvsps, which >>> > you may already have. >>> > >>> > Anyways, here is the first ten lines from a log file >>> of an import >>> > that I just started. >>> > >>> > >>> > peter at black:~ $ head Import-cm3-20090708.log >>> > Running cvsps... >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/.brik on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>> branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>> branch >>> >>> It looks like these files have a second vendor branch >>> without a >>> proper name. CVS does not cope well with multiple vendor >>> branches >>> (in fact it never really worked), but there won't be any >>> valuable >>> information in that branch I'm sure, so you can ignore it. >>> >>> > Later this weekend, I will attempt to use CVSup. >>> First, >>> > I will have to find usable documentation, since I >>> have >>> > never used CVSup before. >>> > >>> > Do you have a script to use with CVSup to access the >>> > CM3 CVS repo? I am lasy. >>> > >>> > I use 'git' for all my current projects. I used >>> to use >>> > CVS, and had started looking into using subversion >>> (SVN), >>> > I even purchased a couple books on SVN. Then >>> 'git' burst >>> > upon the Linux world, and is gaining converts all over >>> the >>> > place. >>> > >>> > It really does provide a better work-flow. The >>> easy >>> > creation of a branch is a given, it is git's ability >>> > to do easy merges, which is gaining all the good >>> reputation. >>> > >>> > Rather than get all evangelistic on you, as I am sure >>> you >>> > have already heard it many times already. >>> > >>> > Many businesses are moving to git. The only >>> problem some >>> > enterprise companies are having is the ability to >>> restrict >>> > access of authorized users to only portions of the >>> repository. >>> > These types of problems don't effect open source >>> software >>> > development. >>> > >>> > Once I have a working 'git' repository for cm3, I will >>> share >>> > the technique, and maybe, start the foundations for a >>> > transition from CVS, towards 'git'. But I >>> suggest a slow >>> > process, with distinct stages. At any >>> stage we could stop, >>> > or even revert. >>> > >>> > The problem is that once people start using git, they >>> don''t >>> > want to go back to using CVS, or any of the older >>> methods. >>> > Maybe that isn't so much of a problem after all. >>> > >>> > STAGE-1: Simple mirror of the CVS archive, >>> periodically >>> > updated (say once >>> every 6 hours). Document on >>> > web site, as to how >>> to clone, and update a git >>> > repository. No >>> uploads to git. >>> > STAGE-2: Convert web page scripts to use git. >>> > STAGE-3: Convert tinderbox. >>> > STAGE-4: Uploads to git. Install gitosis or >>> similar server >>> > for git uploads. >>> Document the upload process on web >>> > pages. >>> > STAGE-5: CVS mirrors the git repo. Uploads to >>> git only. >>> > STAGE-6: Move last of the CVS people, over to git. >>> > STAGE-7: Remove CVS. (optional) >>> >>> Let's see how far you get. Converting all the >>> infrastructure (scripts >>> and documentation) may be much more work than you imagine. >>> And one >>> we propose a special tool (be it git or svn or mercurial) >>> there will >>> start discussions on what is best and what we should do >>> :-/ >>> >>> So offering an optional alternative access may be a good >>> plan. >>> The majority of users should agree that they want the >>> change though. >>> And we need to consider use of GUIs and Windows users, >>> too. >>> >>> Olaf >>> --Olaf Wagner -- elego Software Solutions GmbH >>> >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>> Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>> 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | >>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>> USt-IdNr: DE163214194 >>> >>> >> >> >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 11 18:21:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 12:21:28 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: Weird. I've just noticed that the collector has been disabled in RTCollector.i3 (not sure why I did that, but it had something to do with Jay's changes to the locking code in ThreadPThread). It should definitely be reverted, but probably exposes some weirdness in Jay's mutex initialization code. Jay, can you help? On 11 Jul 2009, at 11:19, Tony Hosking wrote: > I'd definitely need some way to reproduce the problem. Detailed > instructions would be best. What platform are you running on? > > On 11 Jul 2009, at 06:47, Olaf Wagner wrote: > >> Hm, I'm afraid we may have a regression in the runtime/gc here. >> CVSup always worked without problems for me (and still is copying >> FreeBSD, CM3 and other repositories between various machines for >> me and Elego). Surely CVSup is doing no such thing as keeping >> all its files in memory. >> >> I haven't tried the version Jay put into the CM3 repo though. >> So I see three possibilities: >> >> o Jay introduced the problem in the CVSup sources when he >> adapted them to the current CM3 (low probability). >> >> o You've got a broken runtime / CM3 version (and current >> sources work). I'd guess you are using the current version though. >> >> o We've got a problem in our runtime code, perhaps -- but not >> necessarily -- the garbage collector. >> >> I'd suggest we rule out the second one and you reproduce the problem >> with a current source set (if not done yet). Then let's see what Jay >> and Antony have to say, as they did almost all the source changes >> in that area recently. >> >> Olaf >> >> Quoting Peter Eiserloh : >> >>> Hi Olaf, >>> >>> Well, I tried CVSup, and it started looking real good, until >>> it crashed, with a message from the M3 runtime, saying that >>> NEW could not allocate any memory. >>> >>> So I ran it a second time, and it got further, then crashed >>> again. >>> >>> So, a third time, but with "top" running in another window, >>> and sure enough cvsup, was allocating something like 1.2 GB >>> of data before it was crashing. This is bigger than the >>> CVS repository that it had already downloaded. >>> >>> I am thinking that cvsup is keeping the contents of every >>> file it downloaded in memory. If so, this is a problem. >>> >>> If it is properly removing references, then maybe the >>> garbage collector is failing. This would be a bigger >>> problem, but with our compiler's runtime library. >>> >>> Are other people noticing problems. Is it just me? >>> Am I the only one to attempt downloading the entire >>> CVS repository for CM3? Could you try it? >>> >>> >>> I sent an email to the email listed in cvsup's "about box" >>> (cvsup-bugs at polstra.com), but that failed. The email address >>> no longer works. >>> >>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>> >>> *** >>> *** runtime error: >>> *** NEW() was unable to allocate more memory. >>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>> *** >>> >>> Aborted >>> >>> Peter >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>> >>>> From: Olaf Wagner >>>> Subject: Re: m3gdb and YACC >>>> To: "Peter Eiserloh" >>>> Date: Saturday, July 11, 2009, 2:49 AM >>>> Quoting Peter Eiserloh : >>>> >>>> > Hi Olaf, >>>> > >>>> > The import script (git-importcvs) internally uses >>>> cvsps, which >>>> > you may already have. >>>> > >>>> > Anyways, here is the first ten lines from a log file >>>> of an import >>>> > that I just started. >>>> > >>>> > >>>> > peter at black:~ $ head Import-cm3-20090708.log >>>> > Running cvsps... >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>> branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>> branch >>>> >>>> It looks like these files have a second vendor branch >>>> without a >>>> proper name. CVS does not cope well with multiple vendor >>>> branches >>>> (in fact it never really worked), but there won't be any >>>> valuable >>>> information in that branch I'm sure, so you can ignore it. >>>> >>>> > Later this weekend, I will attempt to use CVSup. >>>> First, >>>> > I will have to find usable documentation, since I >>>> have >>>> > never used CVSup before. >>>> > >>>> > Do you have a script to use with CVSup to access the >>>> > CM3 CVS repo? I am lasy. >>>> > >>>> > I use 'git' for all my current projects. I used >>>> to use >>>> > CVS, and had started looking into using subversion >>>> (SVN), >>>> > I even purchased a couple books on SVN. Then >>>> 'git' burst >>>> > upon the Linux world, and is gaining converts all over >>>> the >>>> > place. >>>> > >>>> > It really does provide a better work-flow. The >>>> easy >>>> > creation of a branch is a given, it is git's ability >>>> > to do easy merges, which is gaining all the good >>>> reputation. >>>> > >>>> > Rather than get all evangelistic on you, as I am sure >>>> you >>>> > have already heard it many times already. >>>> > >>>> > Many businesses are moving to git. The only >>>> problem some >>>> > enterprise companies are having is the ability to >>>> restrict >>>> > access of authorized users to only portions of the >>>> repository. >>>> > These types of problems don't effect open source >>>> software >>>> > development. >>>> > >>>> > Once I have a working 'git' repository for cm3, I will >>>> share >>>> > the technique, and maybe, start the foundations for a >>>> > transition from CVS, towards 'git'. But I >>>> suggest a slow >>>> > process, with distinct stages. At any >>>> stage we could stop, >>>> > or even revert. >>>> > >>>> > The problem is that once people start using git, they >>>> don''t >>>> > want to go back to using CVS, or any of the older >>>> methods. >>>> > Maybe that isn't so much of a problem after all. >>>> > >>>> > STAGE-1: Simple mirror of the CVS archive, >>>> periodically >>>> > updated (say once >>>> every 6 hours). Document on >>>> > web site, as to how >>>> to clone, and update a git >>>> > repository. No >>>> uploads to git. >>>> > STAGE-2: Convert web page scripts to use git. >>>> > STAGE-3: Convert tinderbox. >>>> > STAGE-4: Uploads to git. Install gitosis or >>>> similar server >>>> > for git uploads. >>>> Document the upload process on web >>>> > pages. >>>> > STAGE-5: CVS mirrors the git repo. Uploads to >>>> git only. >>>> > STAGE-6: Move last of the CVS people, over to git. >>>> > STAGE-7: Remove CVS. (optional) >>>> >>>> Let's see how far you get. Converting all the >>>> infrastructure (scripts >>>> and documentation) may be much more work than you imagine. >>>> And one >>>> we propose a special tool (be it git or svn or mercurial) >>>> there will >>>> start discussions on what is best and what we should do >>>> :-/ >>>> >>>> So offering an optional alternative access may be a good >>>> plan. >>>> The majority of users should agree that they want the >>>> change though. >>>> And we need to consider use of GUIs and Windows users, >>>> too. >>>> >>>> Olaf >>>> --Olaf Wagner -- elego Software Solutions GmbH >>>> >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>> Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>> 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>> >>> >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 11 19:12:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 13:12:19 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> Not sure how it happened, but the collector was turned off by default. It works for me now with the latest updates. On 11 Jul 2009, at 12:21, Tony Hosking wrote: > Weird. I've just noticed that the collector has been disabled in > RTCollector.i3 (not sure why I did that, but it had something to do > with Jay's changes to the locking code in ThreadPThread). It should > definitely be reverted, but probably exposes some weirdness in Jay's > mutex initialization code. Jay, can you help? > > > On 11 Jul 2009, at 11:19, Tony Hosking wrote: > >> I'd definitely need some way to reproduce the problem. Detailed >> instructions would be best. What platform are you running on? >> >> On 11 Jul 2009, at 06:47, Olaf Wagner wrote: >> >>> Hm, I'm afraid we may have a regression in the runtime/gc here. >>> CVSup always worked without problems for me (and still is copying >>> FreeBSD, CM3 and other repositories between various machines for >>> me and Elego). Surely CVSup is doing no such thing as keeping >>> all its files in memory. >>> >>> I haven't tried the version Jay put into the CM3 repo though. >>> So I see three possibilities: >>> >>> o Jay introduced the problem in the CVSup sources when he >>> adapted them to the current CM3 (low probability). >>> >>> o You've got a broken runtime / CM3 version (and current >>> sources work). I'd guess you are using the current version though. >>> >>> o We've got a problem in our runtime code, perhaps -- but not >>> necessarily -- the garbage collector. >>> >>> I'd suggest we rule out the second one and you reproduce the problem >>> with a current source set (if not done yet). Then let's see what Jay >>> and Antony have to say, as they did almost all the source changes >>> in that area recently. >>> >>> Olaf >>> >>> Quoting Peter Eiserloh : >>> >>>> Hi Olaf, >>>> >>>> Well, I tried CVSup, and it started looking real good, until >>>> it crashed, with a message from the M3 runtime, saying that >>>> NEW could not allocate any memory. >>>> >>>> So I ran it a second time, and it got further, then crashed >>>> again. >>>> >>>> So, a third time, but with "top" running in another window, >>>> and sure enough cvsup, was allocating something like 1.2 GB >>>> of data before it was crashing. This is bigger than the >>>> CVS repository that it had already downloaded. >>>> >>>> I am thinking that cvsup is keeping the contents of every >>>> file it downloaded in memory. If so, this is a problem. >>>> >>>> If it is properly removing references, then maybe the >>>> garbage collector is failing. This would be a bigger >>>> problem, but with our compiler's runtime library. >>>> >>>> Are other people noticing problems. Is it just me? >>>> Am I the only one to attempt downloading the entire >>>> CVS repository for CM3? Could you try it? >>>> >>>> >>>> I sent an email to the email listed in cvsup's "about box" >>>> (cvsup-bugs at polstra.com), but that failed. The email address >>>> no longer works. >>>> >>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>>> >>>> *** >>>> *** runtime error: >>>> *** NEW() was unable to allocate more memory. >>>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>>> *** >>>> >>>> Aborted >>>> >>>> Peter >>>> >>>> >>>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh | >>>> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>>> >>>>> From: Olaf Wagner >>>>> Subject: Re: m3gdb and YACC >>>>> To: "Peter Eiserloh" >>>>> Date: Saturday, July 11, 2009, 2:49 AM >>>>> Quoting Peter Eiserloh : >>>>> >>>>> > Hi Olaf, >>>>> > >>>>> > The import script (git-importcvs) internally uses >>>>> cvsps, which >>>>> > you may already have. >>>>> > >>>>> > Anyways, here is the first ten lines from a log file >>>>> of an import >>>>> > that I just started. >>>>> > >>>>> > >>>>> > peter at black:~ $ head Import-cm3-20090708.log >>>>> > Running cvsps... >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>>> branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>>> branch >>>>> >>>>> It looks like these files have a second vendor branch >>>>> without a >>>>> proper name. CVS does not cope well with multiple vendor >>>>> branches >>>>> (in fact it never really worked), but there won't be any >>>>> valuable >>>>> information in that branch I'm sure, so you can ignore it. >>>>> >>>>> > Later this weekend, I will attempt to use CVSup. >>>>> First, >>>>> > I will have to find usable documentation, since I >>>>> have >>>>> > never used CVSup before. >>>>> > >>>>> > Do you have a script to use with CVSup to access the >>>>> > CM3 CVS repo? I am lasy. >>>>> > >>>>> > I use 'git' for all my current projects. I used >>>>> to use >>>>> > CVS, and had started looking into using subversion >>>>> (SVN), >>>>> > I even purchased a couple books on SVN. Then >>>>> 'git' burst >>>>> > upon the Linux world, and is gaining converts all over >>>>> the >>>>> > place. >>>>> > >>>>> > It really does provide a better work-flow. The >>>>> easy >>>>> > creation of a branch is a given, it is git's ability >>>>> > to do easy merges, which is gaining all the good >>>>> reputation. >>>>> > >>>>> > Rather than get all evangelistic on you, as I am sure >>>>> you >>>>> > have already heard it many times already. >>>>> > >>>>> > Many businesses are moving to git. The only >>>>> problem some >>>>> > enterprise companies are having is the ability to >>>>> restrict >>>>> > access of authorized users to only portions of the >>>>> repository. >>>>> > These types of problems don't effect open source >>>>> software >>>>> > development. >>>>> > >>>>> > Once I have a working 'git' repository for cm3, I will >>>>> share >>>>> > the technique, and maybe, start the foundations for a >>>>> > transition from CVS, towards 'git'. But I >>>>> suggest a slow >>>>> > process, with distinct stages. At any >>>>> stage we could stop, >>>>> > or even revert. >>>>> > >>>>> > The problem is that once people start using git, they >>>>> don''t >>>>> > want to go back to using CVS, or any of the older >>>>> methods. >>>>> > Maybe that isn't so much of a problem after all. >>>>> > >>>>> > STAGE-1: Simple mirror of the CVS archive, >>>>> periodically >>>>> > updated (say once >>>>> every 6 hours). Document on >>>>> > web site, as to how >>>>> to clone, and update a git >>>>> > repository. No >>>>> uploads to git. >>>>> > STAGE-2: Convert web page scripts to use git. >>>>> > STAGE-3: Convert tinderbox. >>>>> > STAGE-4: Uploads to git. Install gitosis or >>>>> similar server >>>>> > for git uploads. >>>>> Document the upload process on web >>>>> > pages. >>>>> > STAGE-5: CVS mirrors the git repo. Uploads to >>>>> git only. >>>>> > STAGE-6: Move last of the CVS people, over to git. >>>>> > STAGE-7: Remove CVS. (optional) >>>>> >>>>> Let's see how far you get. Converting all the >>>>> infrastructure (scripts >>>>> and documentation) may be much more work than you imagine. >>>>> And one >>>>> we propose a special tool (be it git or svn or mercurial) >>>>> there will >>>>> start discussions on what is best and what we should do >>>>> :-/ >>>>> >>>>> So offering an optional alternative access may be a good >>>>> plan. >>>>> The majority of users should agree that they want the >>>>> change though. >>>>> And we need to consider use of GUIs and Windows users, >>>>> too. >>>>> >>>>> Olaf >>>>> --Olaf Wagner -- elego Software Solutions GmbH >>>>> >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>>> Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>>> 869 fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | >>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sat Jul 11 22:10:29 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 11 Jul 2009 13:10:29 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <756206.45056.qm@web56807.mail.re3.yahoo.com> Hi Tony, Architecture: AMD64_LINUX. Code base: 20090628. I am untarring 20090710 right now, and will rebuild the CM3 against it using the standard scripts/do-cm3-std.sh I don't expect any difference in behavior though as that is pretty much what my Makefile does anyways. Okay, I can also try this on my old Macintosh (PPC_DARWIN). Are there any additional diagnostics that I can turn on in the runtime? Something simple may help like when NEW complains, printing out: o the size of memory currently allocated, o the current number of allocations, o the total number of allocations performed, o the number of garbage collection runs performed, and o the number of objects reclaimed by the garbage collector, and so forth. This may be difficult since we just failed to allocate, memory, the diagnostics may not have the ability to format strings for output. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 7/11/09, Tony Hosking wrote: > From: Tony Hosking > Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC > To: "Olaf Wagner" > Cc: "Peter Eiserloh" , m3devel at elegosoft.com > Date: Saturday, July 11, 2009, 8:19 AM > I'd definitely need some way to reproduce the > problem. ?Detailed instructions would be best. > ?What platform are you running > on? > On 11 Jul 2009, at 06:47, Olaf > Wagner > wrote: > Hm, I'm afraid we may have a regression > in the runtime/gc here. > CVSup always worked without problems for me (and still is > copying > FreeBSD, CM3 and other repositories between various > machines for > me and Elego). Surely CVSup is doing no such thing as > keeping > all its files in memory. > > I haven't tried the version Jay put into the CM3 repo > though. > So I see three possibilities: > > o Jay introduced the problem in the CVSup sources when he > ??adapted them to the current CM3 (low > probability). > > o You've got a broken runtime / CM3 version (and > current > ??sources work). I'd guess you are using the > current version though. > > o We've got a problem in our runtime code, perhaps -- > but not > ??necessarily -- the garbage collector. > > I'd suggest we rule out the second one and you > reproduce the problem > with a current source set (if not done yet). Then let's > see what Jay > and Antony have to say, as they did almost all the source > changes > in that area recently. > > Olaf > > Quoting Peter Eiserloh : > > Hi Olaf, > > Well, I tried CVSup, > and it started looking real good, until > it crashed, with a > message from the M3 runtime, saying that > NEW could not allocate > any memory. > > So I ran it a second > time, and it got further, then crashed > again. > > So, a third time, but > with "top" running in another window, > and sure enough cvsup, > was allocating something like 1.2 GB > of data before it was > crashing. ?This is bigger than the > CVS repository that it > had already downloaded. > > I am thinking that > cvsup is keeping the contents of every > file it downloaded in > memory. ?If so, this is a problem. > > If it is properly > removing references, then maybe the > garbage collector is > failing. ?This would be a bigger > problem, but with our > compiler's runtime library. > > Are other people > noticing problems. ?Is it just me? > Am I the only one to > attempt downloading the entire > CVS repository for > CM3? ?Could you try it? > > > I sent an email to the > email listed in cvsup's "about box" > (cvsup-bugs at polstra.com), > but that failed. ?The email address > no longer works. > > peter at black:/data/modula-3/cm3 $ > ?debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup > cvsupfile.cm3 > > *** > *** runtime error: > *** > ???NEW() was unable to allocate more memory. > *** > ???file > "../src/runtime/common/RuntimeError.m3", line 63 > *** > > Aborted > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > ?????????????????????????????????????| > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, > Olaf Wagner > wrote: > > From: Olaf Wagner > Subject: Re: m3gdb and > YACC > To: "Peter > Eiserloh" > Date: Saturday, July 11, > 2009, 2:49 AM > Quoting Peter Eiserloh > : > > > Hi Olaf, > > > > The import script > (git-importcvs) internally uses > cvsps, which > > you may already > have. > > > > Anyways, here is > the first ten lines from a log file > of an import > > that I just > started. > > > > > > peter at black:~ $ > head Import-cm3-20090708.log > > Running cvsps... > > WARNING: revision > 1.1.3.1 of file > m3-sys/m3cc/gcc/etc/make-stds.texi? on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on > unnamed branch > > WARNING: revision > 1.1.3.1 of file > m3-sys/m3cc/gcc/.brik on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on > unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on > unnamed > branch > > It looks like these > files have a second vendor branch > without a > proper name. CVS does > not cope well with multiple vendor > branches > (in fact it never really > worked), but there won't be any > valuable > information in that > branch I'm sure, so you can ignore it. > > > Later this weekend, > I will attempt to use CVSup.? > First, > > I will have to find > usable documentation, since I > have > > never used CVSup > before. > > > > Do you have a > script to use with CVSup to access the > > CM3 CVS repo?? > I am lasy. > > > > I use 'git' > for all my current projects.? I used > to use > > CVS, and had > started looking into using subversion > (SVN), > > I even purchased a > couple books on SVN.? Then > 'git' burst > > upon the Linux > world, and is gaining converts all over > the > > place. > > > > It really does > provide a better work-flow.? The > easy > > creation of a > branch is a given, it is git's ability > > to do easy merges, > which is gaining all the good > reputation. > > > > Rather than get all > evangelistic on you, as I am sure > you > > have already heard > it many times already. > > > > Many businesses are > moving to git.? The only > problem some > > enterprise > companies are having is the ability to > restrict > > access of > authorized users to only portions of the > repository. > > These types of > problems don't effect open source > software > > development. > > > > Once I have a > working 'git' repository for cm3, I will > share > > the technique, and > maybe, start the foundations for a > > transition from > CVS, towards 'git'.? But I > suggest a slow > > process, with > distinct stages.???At any > stage we could stop, > > or even revert. > > > > The problem is that > once people start using git, they > don''t > > want to go back to > using CVS, or any of the older > methods. > > Maybe that > isn't so much of a problem after all. > > > > STAGE-1: Simple > mirror of the CVS archive, > periodically > >? ? ? > ? ? updated (say once > every 6 hours).? > Document on > >? ? ? > ? ? web site, as to how > to clone, and update a > git > >? ? ? > ? ? repository.? No > uploads to git. > > STAGE-2: Convert > web page scripts to use git. > > STAGE-3: Convert > tinderbox. > > STAGE-4: Uploads to > git.? Install gitosis or > similar server > >? ? ? > ? ? for git uploads. > Document the upload > process on web > >? ? ? > ? ? pages. > > STAGE-5: CVS > mirrors the git repo.? Uploads to > git only. > > STAGE-6: Move last > of the CVS people, over to git. > > STAGE-7: Remove > CVS.? (optional) > > Let's see how far > you get. Converting all the > infrastructure (scripts > and documentation) may > be much more work than you imagine. > And one > we propose a special > tool (be it git or svn or mercurial) > there will > start discussions on > what is best and what we should do > :-/ > > So offering an optional > alternative access may be a good > plan. > The majority of users > should agree that they want the > change though. > And we need to consider > use of GUIs and Windows users, > too. > > Olaf > --Olaf Wagner -- elego > Software Solutions GmbH > ? ? ? > ? ? ? > ???Gustav-Meyer-Allee 25 / > Geb?ude 12, 13355 > Berlin, Germany > phone: +49 30 23 45 86 > 96? mobile: +49 177 2345 > 869? fax: +49 30 23 > 45 86 95 > ???http://www.elegosoft.com > | > Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > Handelregister: > Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > > ??????????????Gustav-Meyer-Allee > 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 ?mobile: +49 177 2345 869 > ?fax: +49 30 23 45 86 95 > ??http://www.elegosoft.com > | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > From wagner at elegosoft.com Sat Jul 11 23:16:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Jul 2009 23:16:51 +0200 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> Message-ID: <20090711231651.tvmtsb7s0004g0kk@mail.elegosoft.com> Quoting Tony Hosking : > Not sure how it happened, but the collector was turned off by default. > It works for me now with the latest updates. Great, thanks for the quick check and help. I assume this will resolve Peter's problems... Olaf > On 11 Jul 2009, at 12:21, Tony Hosking wrote: > >> Weird. I've just noticed that the collector has been disabled in >> RTCollector.i3 (not sure why I did that, but it had something to do >> with Jay's changes to the locking code in ThreadPThread). It >> should definitely be reverted, but probably exposes some weirdness >> in Jay's mutex initialization code. Jay, can you help? >> >> >> On 11 Jul 2009, at 11:19, Tony Hosking wrote: >> >>> I'd definitely need some way to reproduce the problem. Detailed >>> instructions would be best. What platform are you running on? >>> >>> On 11 Jul 2009, at 06:47, Olaf Wagner wrote: >>> >>>> Hm, I'm afraid we may have a regression in the runtime/gc here. >>>> CVSup always worked without problems for me (and still is copying >>>> FreeBSD, CM3 and other repositories between various machines for >>>> me and Elego). Surely CVSup is doing no such thing as keeping >>>> all its files in memory. >>>> >>>> I haven't tried the version Jay put into the CM3 repo though. >>>> So I see three possibilities: >>>> >>>> o Jay introduced the problem in the CVSup sources when he >>>> adapted them to the current CM3 (low probability). >>>> >>>> o You've got a broken runtime / CM3 version (and current >>>> sources work). I'd guess you are using the current version though. >>>> >>>> o We've got a problem in our runtime code, perhaps -- but not >>>> necessarily -- the garbage collector. >>>> >>>> I'd suggest we rule out the second one and you reproduce the problem >>>> with a current source set (if not done yet). Then let's see what Jay >>>> and Antony have to say, as they did almost all the source changes >>>> in that area recently. >>>> >>>> Olaf >>>> >>>> Quoting Peter Eiserloh : >>>> >>>>> Hi Olaf, >>>>> >>>>> Well, I tried CVSup, and it started looking real good, until >>>>> it crashed, with a message from the M3 runtime, saying that >>>>> NEW could not allocate any memory. >>>>> >>>>> So I ran it a second time, and it got further, then crashed >>>>> again. >>>>> >>>>> So, a third time, but with "top" running in another window, >>>>> and sure enough cvsup, was allocating something like 1.2 GB >>>>> of data before it was crashing. This is bigger than the >>>>> CVS repository that it had already downloaded. >>>>> >>>>> I am thinking that cvsup is keeping the contents of every >>>>> file it downloaded in memory. If so, this is a problem. >>>>> >>>>> If it is properly removing references, then maybe the >>>>> garbage collector is failing. This would be a bigger >>>>> problem, but with our compiler's runtime library. >>>>> >>>>> Are other people noticing problems. Is it just me? >>>>> Am I the only one to attempt downloading the entire >>>>> CVS repository for CM3? Could you try it? >>>>> >>>>> >>>>> I sent an email to the email listed in cvsup's "about box" >>>>> (cvsup-bugs at polstra.com), but that failed. The email address >>>>> no longer works. >>>>> >>>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** NEW() was unable to allocate more memory. >>>>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>>>> *** >>>>> >>>>> Aborted >>>>> >>>>> Peter >>>>> >>>>> >>>>> +--------------------------------------------------------+ >>>>> | Peter P. Eiserloh | >>>>> +--------------------------------------------------------+ >>>>> >>>>> >>>>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>>>> >>>>>> From: Olaf Wagner >>>>>> Subject: Re: m3gdb and YACC >>>>>> To: "Peter Eiserloh" >>>>>> Date: Saturday, July 11, 2009, 2:49 AM >>>>>> Quoting Peter Eiserloh : >>>>>> >>>>>>> Hi Olaf, >>>>>>> >>>>>>> The import script (git-importcvs) internally uses >>>>>> cvsps, which >>>>>>> you may already have. >>>>>>> >>>>>>> Anyways, here is the first ten lines from a log file >>>>>> of an import >>>>>>> that I just started. >>>>>>> >>>>>>> >>>>>>> peter at black:~ $ head Import-cm3-20090708.log >>>>>>> Running cvsps... >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>>>> branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>>>> branch >>>>>> >>>>>> It looks like these files have a second vendor branch >>>>>> without a >>>>>> proper name. CVS does not cope well with multiple vendor >>>>>> branches >>>>>> (in fact it never really worked), but there won't be any >>>>>> valuable >>>>>> information in that branch I'm sure, so you can ignore it. >>>>>> >>>>>>> Later this weekend, I will attempt to use CVSup. >>>>>> First, >>>>>>> I will have to find usable documentation, since I >>>>>> have >>>>>>> never used CVSup before. >>>>>>> >>>>>>> Do you have a script to use with CVSup to access the >>>>>>> CM3 CVS repo? I am lasy. >>>>>>> >>>>>>> I use 'git' for all my current projects. I used >>>>>> to use >>>>>>> CVS, and had started looking into using subversion >>>>>> (SVN), >>>>>>> I even purchased a couple books on SVN. Then >>>>>> 'git' burst >>>>>>> upon the Linux world, and is gaining converts all over >>>>>> the >>>>>>> place. >>>>>>> >>>>>>> It really does provide a better work-flow. The >>>>>> easy >>>>>>> creation of a branch is a given, it is git's ability >>>>>>> to do easy merges, which is gaining all the good >>>>>> reputation. >>>>>>> >>>>>>> Rather than get all evangelistic on you, as I am sure >>>>>> you >>>>>>> have already heard it many times already. >>>>>>> >>>>>>> Many businesses are moving to git. The only >>>>>> problem some >>>>>>> enterprise companies are having is the ability to >>>>>> restrict >>>>>>> access of authorized users to only portions of the >>>>>> repository. >>>>>>> These types of problems don't effect open source >>>>>> software >>>>>>> development. >>>>>>> >>>>>>> Once I have a working 'git' repository for cm3, I will >>>>>> share >>>>>>> the technique, and maybe, start the foundations for a >>>>>>> transition from CVS, towards 'git'. But I >>>>>> suggest a slow >>>>>>> process, with distinct stages. At any >>>>>> stage we could stop, >>>>>>> or even revert. >>>>>>> >>>>>>> The problem is that once people start using git, they >>>>>> don''t >>>>>>> want to go back to using CVS, or any of the older >>>>>> methods. >>>>>>> Maybe that isn't so much of a problem after all. >>>>>>> >>>>>>> STAGE-1: Simple mirror of the CVS archive, >>>>>> periodically >>>>>>> updated (say once >>>>>> every 6 hours). Document on >>>>>>> web site, as to how >>>>>> to clone, and update a git >>>>>>> repository. No >>>>>> uploads to git. >>>>>>> STAGE-2: Convert web page scripts to use git. >>>>>>> STAGE-3: Convert tinderbox. >>>>>>> STAGE-4: Uploads to git. Install gitosis or >>>>>> similar server >>>>>>> for git uploads. >>>>>> Document the upload process on web >>>>>>> pages. >>>>>>> STAGE-5: CVS mirrors the git repo. Uploads to >>>>>> git only. >>>>>>> STAGE-6: Move last of the CVS people, over to git. >>>>>>> STAGE-7: Remove CVS. (optional) >>>>>> >>>>>> Let's see how far you get. Converting all the >>>>>> infrastructure (scripts >>>>>> and documentation) may be much more work than you imagine. >>>>>> And one >>>>>> we propose a special tool (be it git or svn or mercurial) >>>>>> there will >>>>>> start discussions on what is best and what we should do >>>>>> :-/ >>>>>> >>>>>> So offering an optional alternative access may be a good >>>>>> plan. >>>>>> The majority of users should agree that they want the >>>>>> change though. >>>>>> And we need to consider use of GUIs and Windows users, >>>>>> too. >>>>>> >>>>>> Olaf >>>>>> --Olaf Wagner -- elego Software Solutions GmbH >>>>>> >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>>>> Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>>>> 869 fax: +49 30 23 45 86 95 >>>>>> http://www.elegosoft.com | >>>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>>>> USt-IdNr: DE163214194 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>> 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 11 23:31:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 17:31:54 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <756206.45056.qm@web56807.mail.re3.yahoo.com> References: <756206.45056.qm@web56807.mail.re3.yahoo.com> Message-ID: <74B566D0-7F39-44B4-BE95-2A743DAB639F@cs.purdue.edu> Please try my recent commits from earlier to day. On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: > > Hi Tony, > > Architecture: AMD64_LINUX. > Code base: 20090628. > > I am untarring 20090710 right now, and will rebuild the > CM3 against it using the standard scripts/do-cm3-std.sh > > I don't expect any difference in behavior though as that > is pretty much what my Makefile does anyways. > > Okay, I can also try this on my old Macintosh (PPC_DARWIN). > > > Are there any additional diagnostics that I can turn on > in the runtime? Something simple may help like when NEW > complains, printing out: > o the size of memory currently allocated, > o the current number of allocations, > o the total number of allocations performed, > o the number of garbage collection runs performed, and > o the number of objects reclaimed by the garbage collector, > and so forth. > > This may be difficult since we just failed to allocate, > memory, the diagnostics may not have the ability to > format strings for output. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Tony Hosking wrote: > >> From: Tony Hosking >> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >> To: "Olaf Wagner" >> Cc: "Peter Eiserloh" , m3devel at elegosoft.com >> Date: Saturday, July 11, 2009, 8:19 AM >> I'd definitely need some way to reproduce the >> problem. Detailed instructions would be best. >> What platform are you running >> on? >> On 11 Jul 2009, at 06:47, Olaf >> Wagner >> wrote: >> Hm, I'm afraid we may have a regression >> in the runtime/gc here. >> CVSup always worked without problems for me (and still is >> copying >> FreeBSD, CM3 and other repositories between various >> machines for >> me and Elego). Surely CVSup is doing no such thing as >> keeping >> all its files in memory. >> >> I haven't tried the version Jay put into the CM3 repo >> though. >> So I see three possibilities: >> >> o Jay introduced the problem in the CVSup sources when he >> adapted them to the current CM3 (low >> probability). >> >> o You've got a broken runtime / CM3 version (and >> current >> sources work). I'd guess you are using the >> current version though. >> >> o We've got a problem in our runtime code, perhaps -- >> but not >> necessarily -- the garbage collector. >> >> I'd suggest we rule out the second one and you >> reproduce the problem >> with a current source set (if not done yet). Then let's >> see what Jay >> and Antony have to say, as they did almost all the source >> changes >> in that area recently. >> >> Olaf >> >> Quoting Peter Eiserloh : >> >> Hi Olaf, >> >> Well, I tried CVSup, >> and it started looking real good, until >> it crashed, with a >> message from the M3 runtime, saying that >> NEW could not allocate >> any memory. >> >> So I ran it a second >> time, and it got further, then crashed >> again. >> >> So, a third time, but >> with "top" running in another window, >> and sure enough cvsup, >> was allocating something like 1.2 GB >> of data before it was >> crashing. This is bigger than the >> CVS repository that it >> had already downloaded. >> >> I am thinking that >> cvsup is keeping the contents of every >> file it downloaded in >> memory. If so, this is a problem. >> >> If it is properly >> removing references, then maybe the >> garbage collector is >> failing. This would be a bigger >> problem, but with our >> compiler's runtime library. >> >> Are other people >> noticing problems. Is it just me? >> Am I the only one to >> attempt downloading the entire >> CVS repository for >> CM3? Could you try it? >> >> >> I sent an email to the >> email listed in cvsup's "about box" >> (cvsup-bugs at polstra.com), >> but that failed. The email address >> no longer works. >> >> peter at black:/data/modula-3/cm3 $ >> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >> cvsupfile.cm3 >> >> *** >> *** runtime error: >> *** >> NEW() was unable to allocate more memory. >> *** >> file >> "../src/runtime/common/RuntimeError.m3", line 63 >> *** >> >> Aborted >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh >> | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, >> Olaf Wagner >> wrote: >> >> From: Olaf Wagner >> Subject: Re: m3gdb and >> YACC >> To: "Peter >> Eiserloh" >> Date: Saturday, July 11, >> 2009, 2:49 AM >> Quoting Peter Eiserloh >> : >> >>> Hi Olaf, >>> >>> The import script >> (git-importcvs) internally uses >> cvsps, which >>> you may already >> have. >>> >>> Anyways, here is >> the first ten lines from a log file >> of an import >>> that I just >> started. >>> >>> >>> peter at black:~ $ >> head Import-cm3-20090708.log >>> Running cvsps... >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/etc/make-stds.texi on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/.brik on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >> unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >> unnamed >> branch >> >> It looks like these >> files have a second vendor branch >> without a >> proper name. CVS does >> not cope well with multiple vendor >> branches >> (in fact it never really >> worked), but there won't be any >> valuable >> information in that >> branch I'm sure, so you can ignore it. >> >>> Later this weekend, >> I will attempt to use CVSup. >> First, >>> I will have to find >> usable documentation, since I >> have >>> never used CVSup >> before. >>> >>> Do you have a >> script to use with CVSup to access the >>> CM3 CVS repo? >> I am lasy. >>> >>> I use 'git' >> for all my current projects. I used >> to use >>> CVS, and had >> started looking into using subversion >> (SVN), >>> I even purchased a >> couple books on SVN. Then >> 'git' burst >>> upon the Linux >> world, and is gaining converts all over >> the >>> place. >>> >>> It really does >> provide a better work-flow. The >> easy >>> creation of a >> branch is a given, it is git's ability >>> to do easy merges, >> which is gaining all the good >> reputation. >>> >>> Rather than get all >> evangelistic on you, as I am sure >> you >>> have already heard >> it many times already. >>> >>> Many businesses are >> moving to git. The only >> problem some >>> enterprise >> companies are having is the ability to >> restrict >>> access of >> authorized users to only portions of the >> repository. >>> These types of >> problems don't effect open source >> software >>> development. >>> >>> Once I have a >> working 'git' repository for cm3, I will >> share >>> the technique, and >> maybe, start the foundations for a >>> transition from >> CVS, towards 'git'. But I >> suggest a slow >>> process, with >> distinct stages. At any >> stage we could stop, >>> or even revert. >>> >>> The problem is that >> once people start using git, they >> don''t >>> want to go back to >> using CVS, or any of the older >> methods. >>> Maybe that >> isn't so much of a problem after all. >>> >>> STAGE-1: Simple >> mirror of the CVS archive, >> periodically >>> >> updated (say once >> every 6 hours). >> Document on >>> >> web site, as to how >> to clone, and update a >> git >>> >> repository. No >> uploads to git. >>> STAGE-2: Convert >> web page scripts to use git. >>> STAGE-3: Convert >> tinderbox. >>> STAGE-4: Uploads to >> git. Install gitosis or >> similar server >>> >> for git uploads. >> Document the upload >> process on web >>> >> pages. >>> STAGE-5: CVS >> mirrors the git repo. Uploads to >> git only. >>> STAGE-6: Move last >> of the CVS people, over to git. >>> STAGE-7: Remove >> CVS. (optional) >> >> Let's see how far >> you get. Converting all the >> infrastructure (scripts >> and documentation) may >> be much more work than you imagine. >> And one >> we propose a special >> tool (be it git or svn or mercurial) >> there will >> start discussions on >> what is best and what we should do >> :-/ >> >> So offering an optional >> alternative access may be a good >> plan. >> The majority of users >> should agree that they want the >> change though. >> And we need to consider >> use of GUIs and Windows users, >> too. >> >> Olaf >> --Olaf Wagner -- elego >> Software Solutions GmbH >> >> >> Gustav-Meyer-Allee 25 / >> Geb?ude 12, 13355 >> Berlin, Germany >> phone: +49 30 23 45 86 >> 96 mobile: +49 177 2345 >> 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com >> | >> Gesch?ftsf?hrer: Olaf >> Wagner | Sitz: Berlin >> Handelregister: >> Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> >> >> >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> >> Gustav-Meyer-Allee >> 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 >> fax: +49 30 23 45 86 95 >> http://www.elegosoft.com >> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> >> > > > From eiserlohpp at yahoo.com Sun Jul 12 20:26:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 12 Jul 2009 11:26:12 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <195840.65922.qm@web56808.mail.re3.yahoo.com> Hi Tony, Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz right now. In the mean time, I wish to report that CVSup on PPC_DARWIN built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, did run to completion. Top indicated that over 2 GB of virtual memory was being used, and over 700 MB of resident memory (ie, RAM). CVSup, used most of my CPU, making any other process (such as Finder) very difficult from which to work. Maybe we should "nice" it, or recommend is be run with "nice". Oh, well one thing at a time. BTW: The "about" box, found by clicking on the little "i" icon in the lower right corner is woefully out of date (eg. I had tried to report bugs to cvsup-bugs at polstra.org, but the email failed to get delivered). The copyright is also listed as 2003, six years ago. The reference to cvsup.org does work however. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 7/11/09, Tony Hosking wrote: > From: Tony Hosking > Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC > To: "Peter Eiserloh" > Cc: "Olaf Wagner" , m3devel at elegosoft.com > Date: Saturday, July 11, 2009, 2:31 PM > Please try my recent commits from > earlier to day. > > On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: > > > > > Hi Tony, > > > > Architecture: AMD64_LINUX. > > Code base: 20090628. > > > > I am untarring 20090710 right now, and will rebuild > the > > CM3 against it using the standard > scripts/do-cm3-std.sh > > > > I don't expect any difference in behavior though as > that > > is pretty much what my Makefile does anyways. > > > > Okay, I can also try this on my old Macintosh > (PPC_DARWIN). > > > > > > Are there any additional diagnostics that I can turn > on > > in the runtime?? Something simple may help like > when NEW > > complains, printing out: > >? o the size of memory currently allocated, > >? o the current number of allocations, > >? o the total number of allocations performed, > >? o the number of garbage collection runs > performed, and > >? o the number of objects reclaimed by the garbage > collector, > > and so forth. > > > > This may be difficult since we just failed to > allocate, > > memory, the diagnostics may not have the ability to > > format strings for output. > > > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? | > > > +--------------------------------------------------------+ > > > > > > --- On Sat, 7/11/09, Tony Hosking > wrote: > > > >> From: Tony Hosking > >> Subject: Re: [M3devel] CVSup crashing WAS: Re: > m3gdb and YACC > >> To: "Olaf Wagner" > >> Cc: "Peter Eiserloh" , > m3devel at elegosoft.com > >> Date: Saturday, July 11, 2009, 8:19 AM > >> I'd definitely need some way to reproduce the > >> problem.? Detailed instructions would be > best. > >>? What platform are you running > >> on? > >> On 11 Jul 2009, at 06:47, Olaf > >> Wagner > >> wrote: > >> Hm, I'm afraid we may have a regression > >> in the runtime/gc here. > >> CVSup always worked without problems for me (and > still is > >> copying > >> FreeBSD, CM3 and other repositories between > various > >> machines for > >> me and Elego). Surely CVSup is doing no such thing > as > >> keeping > >> all its files in memory. > >> > >> I haven't tried the version Jay put into the CM3 > repo > >> though. > >> So I see three possibilities: > >> > >> o Jay introduced the problem in the CVSup sources > when he > >>???adapted them to the current CM3 > (low > >> probability). > >> > >> o You've got a broken runtime / CM3 version (and > >> current > >>???sources work). I'd guess you are > using the > >> current version though. > >> > >> o We've got a problem in our runtime code, perhaps > -- > >> but not > >>???necessarily -- the garbage > collector. > >> > >> I'd suggest we rule out the second one and you > >> reproduce the problem > >> with a current source set (if not done yet). Then > let's > >> see what Jay > >> and Antony have to say, as they did almost all the > source > >> changes > >> in that area recently. > >> > >> Olaf > >> > >> Quoting Peter Eiserloh : > >> > >> Hi Olaf, > >> > >> Well, I tried CVSup, > >> and it started looking real good, until > >> it crashed, with a > >> message from the M3 runtime, saying that > >> NEW could not allocate > >> any memory. > >> > >> So I ran it a second > >> time, and it got further, then crashed > >> again. > >> > >> So, a third time, but > >> with "top" running in another window, > >> and sure enough cvsup, > >> was allocating something like 1.2 GB > >> of data before it was > >> crashing.? This is bigger than the > >> CVS repository that it > >> had already downloaded. > >> > >> I am thinking that > >> cvsup is keeping the contents of every > >> file it downloaded in > >> memory.? If so, this is a problem. > >> > >> If it is properly > >> removing references, then maybe the > >> garbage collector is > >> failing.? This would be a bigger > >> problem, but with our > >> compiler's runtime library. > >> > >> Are other people > >> noticing problems.? Is it just me? > >> Am I the only one to > >> attempt downloading the entire > >> CVS repository for > >> CM3?? Could you try it? > >> > >> > >> I sent an email to the > >> email listed in cvsup's "about box" > >> (cvsup-bugs at polstra.com), > >> but that failed.? The email address > >> no longer works. > >> > >> peter at black:/data/modula-3/cm3 $ > >>? > debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup > >> cvsupfile.cm3 > >> > >> *** > >> *** runtime error: > >> *** > >>? ? NEW() was unable to allocate more > memory. > >> *** > >>? ? file > >> "../src/runtime/common/RuntimeError.m3", line 63 > >> *** > >> > >> Aborted > >> > >> Peter > >> > >> > >> > +--------------------------------------------------------+ > >> | Peter P. Eiserloh > >>? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? | > >> > +--------------------------------------------------------+ > >> > >> > >> --- On Sat, 7/11/09, > >> Olaf Wagner > >> wrote: > >> > >> From: Olaf Wagner > >> Subject: Re: m3gdb and > >> YACC > >> To: "Peter > >> Eiserloh" > >> Date: Saturday, July 11, > >> 2009, 2:49 AM > >> Quoting Peter Eiserloh > >> : > >> > >>> Hi Olaf, > >>> > >>> The import script > >> (git-importcvs) internally uses > >> cvsps, which > >>> you may already > >> have. > >>> > >>> Anyways, here is > >> the first ten lines from a log file > >> of an import > >>> that I just > >> started. > >>> > >>> > >>> peter at black:~ $ > >> head Import-cm3-20090708.log > >>> Running cvsps... > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/etc/make-stds.texi? on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/.brik on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on > >> unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on > >> unnamed > >> branch > >> > >> It looks like these > >> files have a second vendor branch > >> without a > >> proper name. CVS does > >> not cope well with multiple vendor > >> branches > >> (in fact it never really > >> worked), but there won't be any > >> valuable > >> information in that > >> branch I'm sure, so you can ignore it. > >> > >>> Later this weekend, > >> I will attempt to use CVSup. > >> First, > >>> I will have to find > >> usable documentation, since I > >> have > >>> never used CVSup > >> before. > >>> > >>> Do you have a > >> script to use with CVSup to access the > >>> CM3 CVS repo? > >> I am lasy. > >>> > >>> I use 'git' > >> for all my current projects.? I used > >> to use > >>> CVS, and had > >> started looking into using subversion > >> (SVN), > >>> I even purchased a > >> couple books on SVN.? Then > >> 'git' burst > >>> upon the Linux > >> world, and is gaining converts all over > >> the > >>> place. > >>> > >>> It really does > >> provide a better work-flow.? The > >> easy > >>> creation of a > >> branch is a given, it is git's ability > >>> to do easy merges, > >> which is gaining all the good > >> reputation. > >>> > >>> Rather than get all > >> evangelistic on you, as I am sure > >> you > >>> have already heard > >> it many times already. > >>> > >>> Many businesses are > >> moving to git.? The only > >> problem some > >>> enterprise > >> companies are having is the ability to > >> restrict > >>> access of > >> authorized users to only portions of the > >> repository. > >>> These types of > >> problems don't effect open source > >> software > >>> development. > >>> > >>> Once I have a > >> working 'git' repository for cm3, I will > >> share > >>> the technique, and > >> maybe, start the foundations for a > >>> transition from > >> CVS, towards 'git'.? But I > >> suggest a slow > >>> process, with > >> distinct stages.???At any > >> stage we could stop, > >>> or even revert. > >>> > >>> The problem is that > >> once people start using git, they > >> don''t > >>> want to go back to > >> using CVS, or any of the older > >> methods. > >>> Maybe that > >> isn't so much of a problem after all. > >>> > >>> STAGE-1: Simple > >> mirror of the CVS archive, > >> periodically > >>> > >>? ???updated (say once > >> every 6 hours). > >> Document on > >>> > >>? ???web site, as to how > >> to clone, and update a > >> git > >>> > >>? ???repository.? No > >> uploads to git. > >>> STAGE-2: Convert > >> web page scripts to use git. > >>> STAGE-3: Convert > >> tinderbox. > >>> STAGE-4: Uploads to > >> git.? Install gitosis or > >> similar server > >>> > >>? ???for git uploads. > >> Document the upload > >> process on web > >>> > >>? ???pages. > >>> STAGE-5: CVS > >> mirrors the git repo.? Uploads to > >> git only. > >>> STAGE-6: Move last > >> of the CVS people, over to git. > >>> STAGE-7: Remove > >> CVS.? (optional) > >> > >> Let's see how far > >> you get. Converting all the > >> infrastructure (scripts > >> and documentation) may > >> be much more work than you imagine. > >> And one > >> we propose a special > >> tool (be it git or svn or mercurial) > >> there will > >> start discussions on > >> what is best and what we should do > >> :-/ > >> > >> So offering an optional > >> alternative access may be a good > >> plan. > >> The majority of users > >> should agree that they want the > >> change though. > >> And we need to consider > >> use of GUIs and Windows users, > >> too. > >> > >> Olaf > >> --Olaf Wagner -- elego > >> Software Solutions GmbH > >> > >> > >>? ? Gustav-Meyer-Allee 25 / > >> Geb?ude 12, 13355 > >> Berlin, Germany > >> phone: +49 30 23 45 86 > >> 96? mobile: +49 177 2345 > >> 869? fax: +49 30 23 > >> 45 86 95 > >>? ? http://www.elegosoft.com > >> | > >> Gesch?ftsf?hrer: Olaf > >> Wagner | Sitz: Berlin > >> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | > >> USt-IdNr: DE163214194 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Olaf Wagner -- elego Software Solutions GmbH > >> > >>? ? ? ? ? ? > ???Gustav-Meyer-Allee > >> 25 / Geb?ude 12, 13355 Berlin, Germany > >> phone: +49 30 23 45 86 96? mobile: +49 177 > 2345 869 > >>? fax: +49 30 23 45 86 95 > >>???http://www.elegosoft.com > >> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > >> Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > >> USt-IdNr: DE163214194 > >> > >> > >> > > > > > > > > From hosking at cs.purdue.edu Sun Jul 12 21:17:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Jul 2009 15:17:34 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <195840.65922.qm@web56808.mail.re3.yahoo.com> References: <195840.65922.qm@web56808.mail.re3.yahoo.com> Message-ID: You should find the footprint much smaller now. I'm interested to find out what it turns out to be. On 12 Jul 2009, at 14:26, Peter Eiserloh wrote: > > Hi Tony, > > Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz > right now. > > In the mean time, I wish to report that CVSup on PPC_DARWIN > built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, > did run to completion. Top indicated that over 2 GB of > virtual memory was being used, and over 700 MB of resident > memory (ie, RAM). > > CVSup, used most of my CPU, making any other process (such > as Finder) very difficult from which to work. Maybe we should > "nice" it, or recommend is be run with "nice". Oh, well > one thing at a time. > > BTW: The "about" box, found by clicking on the little "i" icon > in the lower right corner is woefully out of date (eg. I had > tried to report bugs to cvsup-bugs at polstra.org, but the email > failed to get delivered). The copyright is also listed as 2003, > six years ago. > > The reference to cvsup.org does work however. > > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Tony Hosking wrote: > >> From: Tony Hosking >> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >> To: "Peter Eiserloh" >> Cc: "Olaf Wagner" , m3devel at elegosoft.com >> Date: Saturday, July 11, 2009, 2:31 PM >> Please try my recent commits from >> earlier to day. >> >> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: >> >>> >>> Hi Tony, >>> >>> Architecture: AMD64_LINUX. >>> Code base: 20090628. >>> >>> I am untarring 20090710 right now, and will rebuild >> the >>> CM3 against it using the standard >> scripts/do-cm3-std.sh >>> >>> I don't expect any difference in behavior though as >> that >>> is pretty much what my Makefile does anyways. >>> >>> Okay, I can also try this on my old Macintosh >> (PPC_DARWIN). >>> >>> >>> Are there any additional diagnostics that I can turn >> on >>> in the runtime? Something simple may help like >> when NEW >>> complains, printing out: >>> o the size of memory currently allocated, >>> o the current number of allocations, >>> o the total number of allocations performed, >>> o the number of garbage collection runs >> performed, and >>> o the number of objects reclaimed by the garbage >> collector, >>> and so forth. >>> >>> This may be difficult since we just failed to >> allocate, >>> memory, the diagnostics may not have the ability to >>> format strings for output. >>> >>> >>> >> +--------------------------------------------------------+ >>> | Peter P. Eiserloh >> >> | >>> >> +--------------------------------------------------------+ >>> >>> >>> --- On Sat, 7/11/09, Tony Hosking >> wrote: >>> >>>> From: Tony Hosking >>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: >> m3gdb and YACC >>>> To: "Olaf Wagner" >>>> Cc: "Peter Eiserloh" , >> m3devel at elegosoft.com >>>> Date: Saturday, July 11, 2009, 8:19 AM >>>> I'd definitely need some way to reproduce the >>>> problem. Detailed instructions would be >> best. >>>> What platform are you running >>>> on? >>>> On 11 Jul 2009, at 06:47, Olaf >>>> Wagner >>>> wrote: >>>> Hm, I'm afraid we may have a regression >>>> in the runtime/gc here. >>>> CVSup always worked without problems for me (and >> still is >>>> copying >>>> FreeBSD, CM3 and other repositories between >> various >>>> machines for >>>> me and Elego). Surely CVSup is doing no such thing >> as >>>> keeping >>>> all its files in memory. >>>> >>>> I haven't tried the version Jay put into the CM3 >> repo >>>> though. >>>> So I see three possibilities: >>>> >>>> o Jay introduced the problem in the CVSup sources >> when he >>>> adapted them to the current CM3 >> (low >>>> probability). >>>> >>>> o You've got a broken runtime / CM3 version (and >>>> current >>>> sources work). I'd guess you are >> using the >>>> current version though. >>>> >>>> o We've got a problem in our runtime code, perhaps >> -- >>>> but not >>>> necessarily -- the garbage >> collector. >>>> >>>> I'd suggest we rule out the second one and you >>>> reproduce the problem >>>> with a current source set (if not done yet). Then >> let's >>>> see what Jay >>>> and Antony have to say, as they did almost all the >> source >>>> changes >>>> in that area recently. >>>> >>>> Olaf >>>> >>>> Quoting Peter Eiserloh : >>>> >>>> Hi Olaf, >>>> >>>> Well, I tried CVSup, >>>> and it started looking real good, until >>>> it crashed, with a >>>> message from the M3 runtime, saying that >>>> NEW could not allocate >>>> any memory. >>>> >>>> So I ran it a second >>>> time, and it got further, then crashed >>>> again. >>>> >>>> So, a third time, but >>>> with "top" running in another window, >>>> and sure enough cvsup, >>>> was allocating something like 1.2 GB >>>> of data before it was >>>> crashing. This is bigger than the >>>> CVS repository that it >>>> had already downloaded. >>>> >>>> I am thinking that >>>> cvsup is keeping the contents of every >>>> file it downloaded in >>>> memory. If so, this is a problem. >>>> >>>> If it is properly >>>> removing references, then maybe the >>>> garbage collector is >>>> failing. This would be a bigger >>>> problem, but with our >>>> compiler's runtime library. >>>> >>>> Are other people >>>> noticing problems. Is it just me? >>>> Am I the only one to >>>> attempt downloading the entire >>>> CVS repository for >>>> CM3? Could you try it? >>>> >>>> >>>> I sent an email to the >>>> email listed in cvsup's "about box" >>>> (cvsup-bugs at polstra.com), >>>> but that failed. The email address >>>> no longer works. >>>> >>>> peter at black:/data/modula-3/cm3 $ >>>> >> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >>>> cvsupfile.cm3 >>>> >>>> *** >>>> *** runtime error: >>>> *** >>>> NEW() was unable to allocate more >> memory. >>>> *** >>>> file >>>> "../src/runtime/common/RuntimeError.m3", line 63 >>>> *** >>>> >>>> Aborted >>>> >>>> Peter >>>> >>>> >>>> >> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh >>>> >> >> | >>>> >> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, >>>> Olaf Wagner >>>> wrote: >>>> >>>> From: Olaf Wagner >>>> Subject: Re: m3gdb and >>>> YACC >>>> To: "Peter >>>> Eiserloh" >>>> Date: Saturday, July 11, >>>> 2009, 2:49 AM >>>> Quoting Peter Eiserloh >>>> : >>>> >>>>> Hi Olaf, >>>>> >>>>> The import script >>>> (git-importcvs) internally uses >>>> cvsps, which >>>>> you may already >>>> have. >>>>> >>>>> Anyways, here is >>>> the first ten lines from a log file >>>> of an import >>>>> that I just >>>> started. >>>>> >>>>> >>>>> peter at black:~ $ >>>> head Import-cm3-20090708.log >>>>> Running cvsps... >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/etc/make-stds.texi on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/.brik on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >>>> unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >>>> unnamed >>>> branch >>>> >>>> It looks like these >>>> files have a second vendor branch >>>> without a >>>> proper name. CVS does >>>> not cope well with multiple vendor >>>> branches >>>> (in fact it never really >>>> worked), but there won't be any >>>> valuable >>>> information in that >>>> branch I'm sure, so you can ignore it. >>>> >>>>> Later this weekend, >>>> I will attempt to use CVSup. >>>> First, >>>>> I will have to find >>>> usable documentation, since I >>>> have >>>>> never used CVSup >>>> before. >>>>> >>>>> Do you have a >>>> script to use with CVSup to access the >>>>> CM3 CVS repo? >>>> I am lasy. >>>>> >>>>> I use 'git' >>>> for all my current projects. I used >>>> to use >>>>> CVS, and had >>>> started looking into using subversion >>>> (SVN), >>>>> I even purchased a >>>> couple books on SVN. Then >>>> 'git' burst >>>>> upon the Linux >>>> world, and is gaining converts all over >>>> the >>>>> place. >>>>> >>>>> It really does >>>> provide a better work-flow. The >>>> easy >>>>> creation of a >>>> branch is a given, it is git's ability >>>>> to do easy merges, >>>> which is gaining all the good >>>> reputation. >>>>> >>>>> Rather than get all >>>> evangelistic on you, as I am sure >>>> you >>>>> have already heard >>>> it many times already. >>>>> >>>>> Many businesses are >>>> moving to git. The only >>>> problem some >>>>> enterprise >>>> companies are having is the ability to >>>> restrict >>>>> access of >>>> authorized users to only portions of the >>>> repository. >>>>> These types of >>>> problems don't effect open source >>>> software >>>>> development. >>>>> >>>>> Once I have a >>>> working 'git' repository for cm3, I will >>>> share >>>>> the technique, and >>>> maybe, start the foundations for a >>>>> transition from >>>> CVS, towards 'git'. But I >>>> suggest a slow >>>>> process, with >>>> distinct stages. At any >>>> stage we could stop, >>>>> or even revert. >>>>> >>>>> The problem is that >>>> once people start using git, they >>>> don''t >>>>> want to go back to >>>> using CVS, or any of the older >>>> methods. >>>>> Maybe that >>>> isn't so much of a problem after all. >>>>> >>>>> STAGE-1: Simple >>>> mirror of the CVS archive, >>>> periodically >>>>> >>>> updated (say once >>>> every 6 hours). >>>> Document on >>>>> >>>> web site, as to how >>>> to clone, and update a >>>> git >>>>> >>>> repository. No >>>> uploads to git. >>>>> STAGE-2: Convert >>>> web page scripts to use git. >>>>> STAGE-3: Convert >>>> tinderbox. >>>>> STAGE-4: Uploads to >>>> git. Install gitosis or >>>> similar server >>>>> >>>> for git uploads. >>>> Document the upload >>>> process on web >>>>> >>>> pages. >>>>> STAGE-5: CVS >>>> mirrors the git repo. Uploads to >>>> git only. >>>>> STAGE-6: Move last >>>> of the CVS people, over to git. >>>>> STAGE-7: Remove >>>> CVS. (optional) >>>> >>>> Let's see how far >>>> you get. Converting all the >>>> infrastructure (scripts >>>> and documentation) may >>>> be much more work than you imagine. >>>> And one >>>> we propose a special >>>> tool (be it git or svn or mercurial) >>>> there will >>>> start discussions on >>>> what is best and what we should do >>>> :-/ >>>> >>>> So offering an optional >>>> alternative access may be a good >>>> plan. >>>> The majority of users >>>> should agree that they want the >>>> change though. >>>> And we need to consider >>>> use of GUIs and Windows users, >>>> too. >>>> >>>> Olaf >>>> --Olaf Wagner -- elego >>>> Software Solutions GmbH >>>> >>>> >>>> Gustav-Meyer-Allee 25 / >>>> Geb?ude 12, 13355 >>>> Berlin, Germany >>>> phone: +49 30 23 45 86 >>>> 96 mobile: +49 177 2345 >>>> 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com >>>> | >>>> Gesch?ftsf?hrer: Olaf >>>> Wagner | Sitz: Berlin >>>> Handelregister: >>>> Amtsgericht Charlottenburg HRB 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> >>>> >> Gustav-Meyer-Allee >>>> 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 869 >>>> fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com >>>> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>>> >>> >>> >>> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 13 04:55:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Jul 2009 02:55:14 +0000 Subject: [M3devel] dynamic linking broken Message-ID: It looks like I might have broken dynamic linking, when I moved .so/.dylib files only to lib and not in pkg. At least on AMD64_DARWIN we get link commands like -L /cm3/pkg/m3core -lm3core but that directory only has libm3core.a. I'll investigate further and fix. Two likely fixes: 1 Change cm3 to point -L always just at /cm3/lib instead of /cm3/pkg. 2 symlink pkg out to lib - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 13 08:53:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 12 Jul 2009 23:53:28 -0700 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <195840.65922.qm@web56808.mail.re3.yahoo.com> Message-ID: <14943A9D-777A-45BE-A993-0289C24209CC@hotmail.com> Am I off the hook? Mika you often test user mode threads right? :) Starting with gc off isn't obviously definitely wrong, could be it gets enabled once initialization is further along. Or not. - Jay (phone) On Jul 12, 2009, at 12:17 PM, Tony Hosking wrote: > You should find the footprint much smaller now. I'm interested to > find out what it turns out to be. > > On 12 Jul 2009, at 14:26, Peter Eiserloh wrote: > >> >> Hi Tony, >> >> Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz >> right now. >> >> In the mean time, I wish to report that CVSup on PPC_DARWIN >> built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, >> did run to completion. Top indicated that over 2 GB of >> virtual memory was being used, and over 700 MB of resident >> memory (ie, RAM). >> >> CVSup, used most of my CPU, making any other process (such >> as Finder) very difficult from which to work. Maybe we should >> "nice" it, or recommend is be run with "nice". Oh, well >> one thing at a time. >> >> BTW: The "about" box, found by clicking on the little "i" icon >> in the lower right corner is woefully out of date (eg. I had >> tried to report bugs to cvsup-bugs at polstra.org, but the email >> failed to get delivered). The copyright is also listed as 2003, >> six years ago. >> >> The reference to cvsup.org does work however. >> >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, Tony Hosking wrote: >> >>> From: Tony Hosking >>> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >>> To: "Peter Eiserloh" >>> Cc: "Olaf Wagner" , m3devel at elegosoft.com >>> Date: Saturday, July 11, 2009, 2:31 PM >>> Please try my recent commits from >>> earlier to day. >>> >>> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: >>> >>>> >>>> Hi Tony, >>>> >>>> Architecture: AMD64_LINUX. >>>> Code base: 20090628. >>>> >>>> I am untarring 20090710 right now, and will rebuild >>> the >>>> CM3 against it using the standard >>> scripts/do-cm3-std.sh >>>> >>>> I don't expect any difference in behavior though as >>> that >>>> is pretty much what my Makefile does anyways. >>>> >>>> Okay, I can also try this on my old Macintosh >>> (PPC_DARWIN). >>>> >>>> >>>> Are there any additional diagnostics that I can turn >>> on >>>> in the runtime? Something simple may help like >>> when NEW >>>> complains, printing out: >>>> o the size of memory currently allocated, >>>> o the current number of allocations, >>>> o the total number of allocations performed, >>>> o the number of garbage collection runs >>> performed, and >>>> o the number of objects reclaimed by the garbage >>> collector, >>>> and so forth. >>>> >>>> This may be difficult since we just failed to >>> allocate, >>>> memory, the diagnostics may not have the ability to >>>> format strings for output. >>>> >>>> >>>> >>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh >>> >>> | >>>> >>> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, Tony Hosking >>> wrote: >>>> >>>>> From: Tony Hosking >>>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: >>> m3gdb and YACC >>>>> To: "Olaf Wagner" >>>>> Cc: "Peter Eiserloh" , >>> m3devel at elegosoft.com >>>>> Date: Saturday, July 11, 2009, 8:19 AM >>>>> I'd definitely need some way to reproduce the >>>>> problem. Detailed instructions would be >>> best. >>>>> What platform are you running >>>>> on? >>>>> On 11 Jul 2009, at 06:47, Olaf >>>>> Wagner >>>>> wrote: >>>>> Hm, I'm afraid we may have a regression >>>>> in the runtime/gc here. >>>>> CVSup always worked without problems for me (and >>> still is >>>>> copying >>>>> FreeBSD, CM3 and other repositories between >>> various >>>>> machines for >>>>> me and Elego). Surely CVSup is doing no such thing >>> as >>>>> keeping >>>>> all its files in memory. >>>>> >>>>> I haven't tried the version Jay put into the CM3 >>> repo >>>>> though. >>>>> So I see three possibilities: >>>>> >>>>> o Jay introduced the problem in the CVSup sources >>> when he >>>>> adapted them to the current CM3 >>> (low >>>>> probability). >>>>> >>>>> o You've got a broken runtime / CM3 version (and >>>>> current >>>>> sources work). I'd guess you are >>> using the >>>>> current version though. >>>>> >>>>> o We've got a problem in our runtime code, perhaps >>> -- >>>>> but not >>>>> necessarily -- the garbage >>> collector. >>>>> >>>>> I'd suggest we rule out the second one and you >>>>> reproduce the problem >>>>> with a current source set (if not done yet). Then >>> let's >>>>> see what Jay >>>>> and Antony have to say, as they did almost all the >>> source >>>>> changes >>>>> in that area recently. >>>>> >>>>> Olaf >>>>> >>>>> Quoting Peter Eiserloh : >>>>> >>>>> Hi Olaf, >>>>> >>>>> Well, I tried CVSup, >>>>> and it started looking real good, until >>>>> it crashed, with a >>>>> message from the M3 runtime, saying that >>>>> NEW could not allocate >>>>> any memory. >>>>> >>>>> So I ran it a second >>>>> time, and it got further, then crashed >>>>> again. >>>>> >>>>> So, a third time, but >>>>> with "top" running in another window, >>>>> and sure enough cvsup, >>>>> was allocating something like 1.2 GB >>>>> of data before it was >>>>> crashing. This is bigger than the >>>>> CVS repository that it >>>>> had already downloaded. >>>>> >>>>> I am thinking that >>>>> cvsup is keeping the contents of every >>>>> file it downloaded in >>>>> memory. If so, this is a problem. >>>>> >>>>> If it is properly >>>>> removing references, then maybe the >>>>> garbage collector is >>>>> failing. This would be a bigger >>>>> problem, but with our >>>>> compiler's runtime library. >>>>> >>>>> Are other people >>>>> noticing problems. Is it just me? >>>>> Am I the only one to >>>>> attempt downloading the entire >>>>> CVS repository for >>>>> CM3? Could you try it? >>>>> >>>>> >>>>> I sent an email to the >>>>> email listed in cvsup's "about box" >>>>> (cvsup-bugs at polstra.com), >>>>> but that failed. The email address >>>>> no longer works. >>>>> >>>>> peter at black:/data/modula-3/cm3 $ >>>>> >>> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >>>>> cvsupfile.cm3 >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** >>>>> NEW() was unable to allocate more >>> memory. >>>>> *** >>>>> file >>>>> "../src/runtime/common/RuntimeError.m3", line 63 >>>>> *** >>>>> >>>>> Aborted >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>> +--------------------------------------------------------+ >>>>> | Peter P. Eiserloh >>>>> >>> >>> | >>>>> >>> +--------------------------------------------------------+ >>>>> >>>>> >>>>> --- On Sat, 7/11/09, >>>>> Olaf Wagner >>>>> wrote: >>>>> >>>>> From: Olaf Wagner >>>>> Subject: Re: m3gdb and >>>>> YACC >>>>> To: "Peter >>>>> Eiserloh" >>>>> Date: Saturday, July 11, >>>>> 2009, 2:49 AM >>>>> Quoting Peter Eiserloh >>>>> : >>>>> >>>>>> Hi Olaf, >>>>>> >>>>>> The import script >>>>> (git-importcvs) internally uses >>>>> cvsps, which >>>>>> you may already >>>>> have. >>>>>> >>>>>> Anyways, here is >>>>> the first ten lines from a log file >>>>> of an import >>>>>> that I just >>>>> started. >>>>>> >>>>>> >>>>>> peter at black:~ $ >>>>> head Import-cm3-20090708.log >>>>>> Running cvsps... >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/.brik on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >>>>> unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >>>>> unnamed >>>>> branch >>>>> >>>>> It looks like these >>>>> files have a second vendor branch >>>>> without a >>>>> proper name. CVS does >>>>> not cope well with multiple vendor >>>>> branches >>>>> (in fact it never really >>>>> worked), but there won't be any >>>>> valuable >>>>> information in that >>>>> branch I'm sure, so you can ignore it. >>>>> >>>>>> Later this weekend, >>>>> I will attempt to use CVSup. >>>>> First, >>>>>> I will have to find >>>>> usable documentation, since I >>>>> have >>>>>> never used CVSup >>>>> before. >>>>>> >>>>>> Do you have a >>>>> script to use with CVSup to access the >>>>>> CM3 CVS repo? >>>>> I am lasy. >>>>>> >>>>>> I use 'git' >>>>> for all my current projects. I used >>>>> to use >>>>>> CVS, and had >>>>> started looking into using subversion >>>>> (SVN), >>>>>> I even purchased a >>>>> couple books on SVN. Then >>>>> 'git' burst >>>>>> upon the Linux >>>>> world, and is gaining converts all over >>>>> the >>>>>> place. >>>>>> >>>>>> It really does >>>>> provide a better work-flow. The >>>>> easy >>>>>> creation of a >>>>> branch is a given, it is git's ability >>>>>> to do easy merges, >>>>> which is gaining all the good >>>>> reputation. >>>>>> >>>>>> Rather than get all >>>>> evangelistic on you, as I am sure >>>>> you >>>>>> have already heard >>>>> it many times already. >>>>>> >>>>>> Many businesses are >>>>> moving to git. The only >>>>> problem some >>>>>> enterprise >>>>> companies are having is the ability to >>>>> restrict >>>>>> access of >>>>> authorized users to only portions of the >>>>> repository. >>>>>> These types of >>>>> problems don't effect open source >>>>> software >>>>>> development. >>>>>> >>>>>> Once I have a >>>>> working 'git' repository for cm3, I will >>>>> share >>>>>> the technique, and >>>>> maybe, start the foundations for a >>>>>> transition from >>>>> CVS, towards 'git'. But I >>>>> suggest a slow >>>>>> process, with >>>>> distinct stages. At any >>>>> stage we could stop, >>>>>> or even revert. >>>>>> >>>>>> The problem is that >>>>> once people start using git, they >>>>> don''t >>>>>> want to go back to >>>>> using CVS, or any of the older >>>>> methods. >>>>>> Maybe that >>>>> isn't so much of a problem after all. >>>>>> >>>>>> STAGE-1: Simple >>>>> mirror of the CVS archive, >>>>> periodically >>>>>> >>>>> updated (say once >>>>> every 6 hours). >>>>> Document on >>>>>> >>>>> web site, as to how >>>>> to clone, and update a >>>>> git >>>>>> >>>>> repository. No >>>>> uploads to git. >>>>>> STAGE-2: Convert >>>>> web page scripts to use git. >>>>>> STAGE-3: Convert >>>>> tinderbox. >>>>>> STAGE-4: Uploads to >>>>> git. Install gitosis or >>>>> similar server >>>>>> >>>>> for git uploads. >>>>> Document the upload >>>>> process on web >>>>>> >>>>> pages. >>>>>> STAGE-5: CVS >>>>> mirrors the git repo. Uploads to >>>>> git only. >>>>>> STAGE-6: Move last >>>>> of the CVS people, over to git. >>>>>> STAGE-7: Remove >>>>> CVS. (optional) >>>>> >>>>> Let's see how far >>>>> you get. Converting all the >>>>> infrastructure (scripts >>>>> and documentation) may >>>>> be much more work than you imagine. >>>>> And one >>>>> we propose a special >>>>> tool (be it git or svn or mercurial) >>>>> there will >>>>> start discussions on >>>>> what is best and what we should do >>>>> :-/ >>>>> >>>>> So offering an optional >>>>> alternative access may be a good >>>>> plan. >>>>> The majority of users >>>>> should agree that they want the >>>>> change though. >>>>> And we need to consider >>>>> use of GUIs and Windows users, >>>>> too. >>>>> >>>>> Olaf >>>>> --Olaf Wagner -- elego >>>>> Software Solutions GmbH >>>>> >>>>> >>>>> Gustav-Meyer-Allee 25 / >>>>> Geb?ude 12, 13355 >>>>> Berlin, Germany >>>>> phone: +49 30 23 45 86 >>>>> 96 mobile: +49 177 2345 >>>>> 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com >>>>> | >>>>> Gesch?ftsf?hrer: Olaf >>>>> Wagner | Sitz: Berlin >>>>> Handelregister: >>>>> Amtsgericht Charlottenburg HRB 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> >>>>> >>> Gustav-Meyer-Allee >>>>> 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 >>> 2345 869 >>>>> fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com >>>>> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB >>> 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 13 08:55:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Jul 2009 08:55:57 +0200 Subject: [M3devel] Fwd: Problems with the linker Message-ID: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> Something for Jay or Randy again... please help to find the correct linker. Olaf ----- Forwarded message from clever92000 at yahoo.com.br ----- Date: Sun, 12 Jul 2009 18:51:48 -0300 From: Cleverson Reply-To: Cleverson Subject: Problems with the linker To: m3-support at elego.de Hello: In case my following question can better be answered at the m3devel mailing list, please subscribe me. I'd like to learn Modula-3, so I'm trying to set up CM3 on my Windows XP system. I'm not sure about the differences between the "bin" and the "std" cm3 distributions, but from what I could understand, the later contains more pre-compiled DLL libraries, so I decided to go with it. I unpacked the file "cm3-std-NT386-d5.8.1.zip" to the root of my E: partition, then renamed the root cm3's folder to cm3, then set the PATH variable to include E:\cm3\bin. When I try to build a hello test program, I receive an error saying it cannot find the "link" command, then the linking process fails. The installation instructions state that I should have the Windows SDK. If my problem is actually that I'm missing it, can you point me to where I can grabe it please? Anyways, I'd like to know why cm3 doesn't have its own linker, that it needs the Windows SDK linker, unlike other language's compilers such as FreePascal? Many thanks for any help Cleverson ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 13 09:17:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Jul 2009 07:17:56 +0000 Subject: [M3devel] Fwd: Problems with the linker In-Reply-To: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> References: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> Message-ID: Please buy or download one of the many Visual C++ versions, or one of the Windows SDKs that include a linker. Once installed, they should put a link on the start menu that launches a cmd/console/command line with %PATH% set to include link.exe. I'll make this a little easier maybe, but you still need a Microsoft linker. Options include but are not limited to: http://www.microsoft.com/express/vc/ This might nag you to register but I think to just use the command line you don't have to. http://www.microsoft.com/downloads/details.aspx?familyid=E6E1C3DF-A74F-4207-8586-711EBE331CDC (see how it says "including compilers") some of these: http://mssdk.orderport.net/22221848/showall.asp - Jay > Date: Mon, 13 Jul 2009 08:55:57 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Problems with the linker > > Something for Jay or Randy again... please help to find the correct linker. > > Olaf > > ----- Forwarded message from clever92000 at yahoo.com.br ----- > Date: Sun, 12 Jul 2009 18:51:48 -0300 > From: Cleverson > Reply-To: Cleverson > Subject: Problems with the linker > To: m3-support at elego.de > > Hello: > > In case my following question can better be answered at the m3devel > mailing list, please subscribe me. > > I'd like to learn Modula-3, so I'm trying to set up CM3 on my Windows XP > system. I'm not sure about the differences between the "bin" and the > "std" cm3 distributions, but from what I could understand, the later > contains more pre-compiled DLL libraries, so I decided to go with it. > > I unpacked the file "cm3-std-NT386-d5.8.1.zip" to the root of my E: > partition, then renamed the root cm3's folder to cm3, then set the PATH > variable to include E:\cm3\bin. When I try to build a hello test > program, I receive an error saying it cannot find the "link" command, > then the linking process fails. > > The installation instructions state that I should have the Windows SDK. > If my problem is actually that I'm missing it, can you point me to where > I can grabe it please? > > Anyways, I'd like to know why cm3 doesn't have its own linker, that it > needs the Windows SDK linker, unlike other language's compilers such as > FreePascal? > > Many thanks for any help > > Cleverson > > > ----- End forwarded message ----- > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Mon Jul 13 12:24:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 13 Jul 2009 03:24:58 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <274088.73864.qm@web56804.mail.re3.yahoo.com> Hi Tony, You recent commit, sure looks like it did the trick. CVSup has gotten to the point where it used to crash, and much further. Where before it used to take up over 75% of my memory, now it is at 1.6% (yes, less than 2%). It has also been working for over 14 minutes, and still going strong. Before it wouldn't last for more than 3 minutes. Thank you very much. Another regression bites the dust! +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > >>> From: Tony Hosking > >>> Subject: Re: [M3devel] CVSup crashing WAS: Re: > m3gdb and YACC > >>> To: "Peter Eiserloh" > >>> Cc: "Olaf Wagner" , > m3devel at elegosoft.com > >>> Date: Saturday, July 11, 2009, 2:31 PM > >>> Please try my recent commits from > >>> earlier to day. > >>> From jay.krell at cornell.edu Tue Jul 14 02:10:30 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 13 Jul 2009 17:10:30 -0700 Subject: [M3devel] dynamic linking broken In-Reply-To: References: Message-ID: <28CA8259-DA9C-4A4F-AA1B-1F01CFE3DE2B@hotmail.com> It should be ok now though I didn't test the solaris part. Hopefully a better construct soon like 'InstallSymbolicLink' without the limitations of the current functions, to reduce the indirection. - Jay (phone) On Jul 12, 2009, at 7:55 PM, Jay K wrote: > It looks like I might have broken dynamic linking, when I > moved .so/.dylib files only to lib and not in pkg. > > At least on AMD64_DARWIN we get link commands like > > -L /cm3/pkg/m3core -lm3core > > but that directory only has libm3core.a. > > I'll investigate further and fix. > > Two likely fixes: > 1 Change cm3 to point -L always just at /cm3/lib instead of /cm3/pkg. > 2 symlink pkg out to lib > > - Jay > > > > From wagner at elegosoft.com Wed Jul 15 08:31:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 08:31:40 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze Message-ID: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Hi all, I'm currently tagging the source base with release_CM3_5_8_RC2. The reported compiler vesion will be d5.8.2 for this RC. There seems to be a neverending stream of commits, which makes it quite difficult to choose a good time to do this, but I hope that Tinderbox will show no major problems with the tagged sources. I'd like everybody for the next weeks to postpone their functional changes and concentrate on testing and fixing bugs that are found or already known. If anybody knows of any problems with the current tag we can still move it in places _before_ we build any release archives. Tagging the whole repository is a quite costly operation in CVS. To summarize: o refrain from functional changes o report and correct bugs o don't build any distribution archives until we've agreed we've tagged a good source set I'll perform some testing myself and try to prepare a draft for the release notes (a lot of changes occured in the recent years) within the next days. Thanks for your patience and your contribution, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 09:27:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 07:27:44 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: How does one checkout, update or commit to RC2 and beyond RC2? There is still maybe the formsedit crash. I'll verify soon. Ideally we get to a situation in which distributions are built every day and what we ship is merely picked among them. I need to ever get Tinderbox working and under cron or in a loop. I also wonder if we should go back to 5.7.something, since we burned through 5.7 fairly fast. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 08:31:40 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: m3-support at elego.de > Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > There seems to be a neverending stream of commits, which makes > it quite difficult to choose a good time to do this, but I hope > that Tinderbox will show no major problems with the tagged sources. > > I'd like everybody for the next weeks to postpone their functional > changes and concentrate on testing and fixing bugs that are found > or already known. If anybody knows of any problems with the current > tag we can still move it in places _before_ we build any release > archives. Tagging the whole repository is a quite costly operation > in CVS. > > To summarize: > > o refrain from functional changes > o report and correct bugs > o don't build any distribution archives until we've agreed we've > tagged a good source set > > I'll perform some testing myself and try to prepare a draft for the > release notes (a lot of changes occured in the recent years) within the > next days. > > Thanks for your patience and your contribution, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 15 11:33:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 11:33:56 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Quoting Jay K : > How does one checkout, update or commit to RC2 and beyond RC2? No changes here. I'd just like to avoid branching for the release, and concentrate work on it. > There is still maybe the formsedit crash. I'll verify soon. > > Ideally we get to a situation in which distributions are built every > day and what we ship is merely picked among them. I need to ever > get Tinderbox working and under cron or in a loop. > > I also wonder if we should go back to 5.7.something, since we burned > through 5.7 fairly fast. Please, let's just provide one stable official release, and not confuse anybody by using old version numbers. Olaf > ---------------------------------------- >> Date: Wed, 15 Jul 2009 08:31:40 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> CC: m3-support at elego.de >> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> There seems to be a neverending stream of commits, which makes >> it quite difficult to choose a good time to do this, but I hope >> that Tinderbox will show no major problems with the tagged sources. >> >> I'd like everybody for the next weeks to postpone their functional >> changes and concentrate on testing and fixing bugs that are found >> or already known. If anybody knows of any problems with the current >> tag we can still move it in places _before_ we build any release >> archives. Tagging the whole repository is a quite costly operation >> in CVS. >> >> To summarize: >> >> o refrain from functional changes >> o report and correct bugs >> o don't build any distribution archives until we've agreed we've >> tagged a good source set >> >> I'll perform some testing myself and try to prepare a draft for the >> release notes (a lot of changes occured in the recent years) within the >> next days. >> >> Thanks for your patience and your contribution, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 13:41:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 11:41:38 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715113356.30raw28b74og08kk@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: I'd still like to: reduce the indirection in the recently introduced symlinks..it is a small change (that's what I always say!) (though the movement from pkg to lib I wouldn't call small) improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others These might be be mostly just: - updating RTSignalC.c - updating the GNU configuration name for AMD64_SOLARIS in m3cc/src/m3makefile - fix my Python scripts to consume the master package list, build m3gdb, build cm3ide, build in dependency order (huh, I thought they always did, now not sure), add your feature of passing on extra parameteres to cm3 - maybe change the *.sh files to accept parameters in any order like the *.py - maybe whittle away more on m3core/src/unix Also some minor features I'll propose shortly. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 11:33:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > Quoting Jay K : > >> How does one checkout, update or commit to RC2 and beyond RC2? > > No changes here. I'd just like to avoid branching for the release, > and concentrate work on it. > >> There is still maybe the formsedit crash. I'll verify soon. >> >> Ideally we get to a situation in which distributions are built every >> day and what we ship is merely picked among them. I need to ever >> get Tinderbox working and under cron or in a loop. >> >> I also wonder if we should go back to 5.7.something, since we burned >> through 5.7 fairly fast. > > Please, let's just provide one stable official release, and not confuse > anybody by using old version numbers. > > Olaf > >> ---------------------------------------- >>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> CC: m3-support at elego.de >>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>> >>> Hi all, >>> >>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>> The reported compiler vesion will be d5.8.2 for this RC. >>> There seems to be a neverending stream of commits, which makes >>> it quite difficult to choose a good time to do this, but I hope >>> that Tinderbox will show no major problems with the tagged sources. >>> >>> I'd like everybody for the next weeks to postpone their functional >>> changes and concentrate on testing and fixing bugs that are found >>> or already known. If anybody knows of any problems with the current >>> tag we can still move it in places _before_ we build any release >>> archives. Tagging the whole repository is a quite costly operation >>> in CVS. >>> >>> To summarize: >>> >>> o refrain from functional changes >>> o report and correct bugs >>> o don't build any distribution archives until we've agreed we've >>> tagged a good source set >>> >>> I'll perform some testing myself and try to prepare a draft for the >>> release notes (a lot of changes occured in the recent years) within the >>> next days. >>> >>> Thanks for your patience and your contribution, >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 15 14:01:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 12:01:43 +0000 Subject: [M3devel] TARGET_OS, TARGET_PROCESSOR, TARGET_ENDIAN? Message-ID: I propose there be quake variables, set by by cm3 in Target.m3 with the possible names/values: TARGET_OS: ?TARGET_KERNEL, ?TARGET_LIBC (which /sort of/ makes sense but surely wouldn't be the conclusion) FREEBSD, NETBSD, OPENBSD, DARWIN, LINUX, SOLARIS, NT, CYGWIN, INETRIX, TRU64 (OSF1?), VMS, HPUX, IRIX, AIX, HERD?, GNUHERD?, GNU??, PLAN9?, MACOS?, DJGPP?, MSDOS? TARGET_PROCESSOR: ?TARGET_CPU, ?TARGET_ARCHITECTURE, ?TARGET_PROCESSOR_ARCHITECTURE I386, AMD64, SPARC, SPARC64, PPC, PPC64, ARM, MIPS, MIPS64, ALPHA, IA64, M68K?, SH3?, SH4? (I doubt these last three will ever be supported.) I grant that this is somewhat redundant with WORD_SIZE. You could just have X86, SPARC, PPC, MIPS, and dispense with AMD64, SPARC64, PPC64, MIPS64. TARGET_ENDIAN: BIG, LITTLE This would allow for much smoother maintenance of a few m3makefiles, since a lot of stuff keyed by TARGET need only be keyed by one of these factors. I also propose, maybe, there be similar HOST_ variables where above I have TARGET_. Though these have far less utility. If I didn't already introduce it, HOST_OSTYPE is about the right thing here -- POSIX or WIN32. I also put in HOST which draws from the same values as TARGET, really just as a default for TARGET when probing for config files. I also grant that I'm ignoring some harder to pin down problems such as "TARGET_ABI" -- 32bit MIPS has two, and IA64 has a surprising number -- there are actually 32bit ABIs on IA64_HPUX, we'd probably never support them. Ideally but not always, TARGET = TARGET_PROCESSOR + TARGET_OS? - Jay From wagner at elegosoft.com Wed Jul 15 16:01:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 16:01:23 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: <20090715160123.zrxx74tg2ssoc8cg@mail.elegosoft.com> Quoting Jay K : > I'd still like to: > > reduce the indirection in the recently introduced symlinks..it is > a small change (that's what I always say!) (though the movement from > pkg to lib I wouldn't call small) > > improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, > AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, > AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others > > These might be be mostly just: > - updating RTSignalC.c Minor corrections and improvements can still be made for the next release candidate (RC3), or release (if we agree that RC2 is OK ;-) > - updating the GNU configuration name for AMD64_SOLARIS in > m3cc/src/m3makefile > - fix my Python scripts to consume the master package list, > build m3gdb, build cm3ide, build in dependency order (huh, I thought > they always did, now not sure), add your feature of passing on > extra parameteres to cm3 > - maybe change the *.sh files to accept parameters in any order > like the *.py > - maybe whittle away more on m3core/src/unix > > Also some minor features I'll propose shortly. Well, we originally wanted to deliver a release (which has been overdue for many years) in May; now it's mid of July. There's always lots of stuff we can improve, but why not do it in the next release? We'll never get anything released if we continue adding new things... Olaf > ---------------------------------------- >> Date: Wed, 15 Jul 2009 11:33:56 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Quoting Jay K : >> >>> How does one checkout, update or commit to RC2 and beyond RC2? >> >> No changes here. I'd just like to avoid branching for the release, >> and concentrate work on it. >> >>> There is still maybe the formsedit crash. I'll verify soon. >>> >>> Ideally we get to a situation in which distributions are built every >>> day and what we ship is merely picked among them. I need to ever >>> get Tinderbox working and under cron or in a loop. >>> >>> I also wonder if we should go back to 5.7.something, since we burned >>> through 5.7 fairly fast. >> >> Please, let's just provide one stable official release, and not confuse >> anybody by using old version numbers. >> >> Olaf >> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: m3-support at elego.de >>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Hi all, >>>> >>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>> The reported compiler vesion will be d5.8.2 for this RC. >>>> There seems to be a neverending stream of commits, which makes >>>> it quite difficult to choose a good time to do this, but I hope >>>> that Tinderbox will show no major problems with the tagged sources. >>>> >>>> I'd like everybody for the next weeks to postpone their functional >>>> changes and concentrate on testing and fixing bugs that are found >>>> or already known. If anybody knows of any problems with the current >>>> tag we can still move it in places _before_ we build any release >>>> archives. Tagging the whole repository is a quite costly operation >>>> in CVS. >>>> >>>> To summarize: >>>> >>>> o refrain from functional changes >>>> o report and correct bugs >>>> o don't build any distribution archives until we've agreed we've >>>> tagged a good source set >>>> >>>> I'll perform some testing myself and try to prepare a draft for the >>>> release notes (a lot of changes occured in the recent years) within the >>>> next days. >>>> >>>> Thanks for your patience and your contribution, >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Wed Jul 15 18:14:45 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Wed, 15 Jul 2009 12:14:45 -0400 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: <4A5DC833.1E75.00D7.1@scires.com> Olaf: Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. I'll try to work on this tonight. Thanks for getting us to this stage in the process! Regards, Randy Coleburn >>> Olaf Wagner 7/15/2009 2:31 AM >>> Hi all, I'm currently tagging the source base with release_CM3_5_8_RC2. The reported compiler vesion will be d5.8.2 for this RC. .. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Wed Jul 15 18:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 16:24:49 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <4A5DC833.1E75.00D7.1@scires.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: I think from Olaf's response to my question, you just do a regular "update" with no special parameters. Can some/all of your applications be in the cm3 repository? - Jay ________________________________ > Date: Wed, 15 Jul 2009 12:14:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Olaf: > > > > Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. > > > > I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. > > > > I'll try to work on this tonight. > > > > Thanks for getting us to this stage in the process! > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/15/2009 2:31 AM>>> > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > ... From wagner at elegosoft.com Wed Jul 15 19:12:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 19:12:41 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: <20090715191241.ykphdt1we68ooccs@mail.elegosoft.com> Quoting Jay K : > > I think from Olaf's response to my question, you just do a regular > "update" with no special parameters. I just checked: there have been no commits since I laid the tag this morning, so the current head is still equal to release_CM3_5_8_RC2. Randy, I haven't got TurtoiseCVS here, but I'd guess you can specify the tag in the checkout of update dialogue. If you check out release_CM3_5_8_RC2, CVS will just make that tag `sticky' (remember it in your workspace) and not let you do any updates (since it is no branch). Jay, I really don't want to repress all your activities, I'd just like you to consider if they are really necessary for this release (candidate) or if they can wait some more days. As I said, we can still incorporate minor improvements by moving the tag, but once we build packages, we should not touch it any more. Everything else can of course go into RC3 as long as it does not challenge the stability. Does that sound OK? Olaf > Can some/all of your applications be in the cm3 repository? > > - Jay > > > ________________________________ >> Date: Wed, 15 Jul 2009 12:14:45 -0400 >> From: rcolebur at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> >> >> >> >> >> >> Olaf: >> >> >> >> Ok, so now that you have RC2, I suppose I need to update my local >> copy of the repository to match RC2, rebuild everything, and test >> my applications to see how it fares. >> >> >> >> I'm using TortoiseCVS. If I just do a CVS update, I get everything >> that has changed in the repository, so I need to do some >> investigating to see how to get just the RC2 stuff. >> >> >> >> I'll try to work on this tonight. >> >> >> >> Thanks for getting us to this stage in the process! >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Olaf Wagner 7/15/2009 2:31 AM>>> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> ... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Wed Jul 15 19:33:36 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Wed, 15 Jul 2009 13:33:36 -0400 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: <4A5DDAB0.1E75.00D7.1@scires.com> Jay, No, I can't put all of my applications into the repository because many of them are "works for hire" and the source code cannot be released to the public domain. Regards, Randy >>> Jay K 7/15/2009 12:24 PM >>> I think from Olaf's response to my question, you just do a regular "update" with no special parameters. Can some/all of your applications be in the cm3 repository? - Jay ________________________________ > Date: Wed, 15 Jul 2009 12:14:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Olaf: > > > > Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. > > > > I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. > > > > I'll try to work on this tonight. > > > > Thanks for getting us to this stage in the process! > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/15/2009 2:31 AM>>> > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Wed Jul 15 19:35:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 19:35:01 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> OK< I've done the first changes to RC2 myself now:-/ cvs commit -m 'consistently rename programs lex, yacc, tok, ext to klex, kyacc, ktok, kext' caltech-parser The following files have been changed: T caltech-parser/parserlib/kext/src/m3makefile T caltech-parser/parserlib/klex/src/m3makefile T caltech-parser/parserlib/ktok/src/m3makefile T caltech-parser/parserlib/kyacc/src/m3makefile T caltech-parser/parserlib/parserlib/src/parser.tmpl I think that change is justified as we do not want to ship competing yaccs and lexs again, that's rather surprising (not to say annoying). I'd suggest we'll wait another day for late fixes and then build the RC2 packages. Any comments/suggestions so far? Olaf Quoting Jay K : > I'd still like to: > > reduce the indirection in the recently introduced symlinks..it is > a small change (that's what I always say!) (though the movement from > pkg to lib I wouldn't call small) > > > improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, > AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, > AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others > > These might be be mostly just: > - updating RTSignalC.c > - updating the GNU configuration name for AMD64_SOLARIS in > m3cc/src/m3makefile > - fix my Python scripts to consume the master package list, > build m3gdb, build cm3ide, build in dependency order (huh, I thought > they always did, now not sure), add your feature of passing on > extra parameteres to cm3 > - maybe change the *.sh files to accept parameters in any order > like the *.py > - maybe whittle away more on m3core/src/unix > > Also some minor features I'll propose shortly. > > - Jay > > > > > > > > ---------------------------------------- >> Date: Wed, 15 Jul 2009 11:33:56 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Quoting Jay K : >> >>> How does one checkout, update or commit to RC2 and beyond RC2? >> >> No changes here. I'd just like to avoid branching for the release, >> and concentrate work on it. >> >>> There is still maybe the formsedit crash. I'll verify soon. >>> >>> Ideally we get to a situation in which distributions are built every >>> day and what we ship is merely picked among them. I need to ever >>> get Tinderbox working and under cron or in a loop. >>> >>> I also wonder if we should go back to 5.7.something, since we burned >>> through 5.7 fairly fast. >> >> Please, let's just provide one stable official release, and not confuse >> anybody by using old version numbers. >> >> Olaf >> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: m3-support at elego.de >>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Hi all, >>>> >>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>> The reported compiler vesion will be d5.8.2 for this RC. >>>> There seems to be a neverending stream of commits, which makes >>>> it quite difficult to choose a good time to do this, but I hope >>>> that Tinderbox will show no major problems with the tagged sources. >>>> >>>> I'd like everybody for the next weeks to postpone their functional >>>> changes and concentrate on testing and fixing bugs that are found >>>> or already known. If anybody knows of any problems with the current >>>> tag we can still move it in places _before_ we build any release >>>> archives. Tagging the whole repository is a quite costly operation >>>> in CVS. >>>> >>>> To summarize: >>>> >>>> o refrain from functional changes >>>> o report and correct bugs >>>> o don't build any distribution archives until we've agreed we've >>>> tagged a good source set >>>> >>>> I'll perform some testing myself and try to prepare a draft for the >>>> release notes (a lot of changes occured in the recent years) within the >>>> next days. >>>> >>>> Thanks for your patience and your contribution, >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 20:35:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 18:35:30 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <4A5DDAB0.1E75.00D7.1@scires.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> <4A5DDAB0.1E75.00D7.1@scires.com> Message-ID: Understood, I had to ask just in case. (I was going to explain the various licenses but...) - Jay ________________________________ > Date: Wed, 15 Jul 2009 13:33:36 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Jay, > > > > No, I can't put all of my applications into the repository because many of them are "works for hire" and the source code cannot be released to the public domain. > > > > Regards, > > Randy > >>>> Jay K 7/15/2009 12:24 PM>>> > > I think from Olaf's response to my question, you just do a regular "update" with no special parameters. > > Can some/all of your applications be in the cm3 repository? > > - Jay > > > ________________________________ >> Date: Wed, 15 Jul 2009 12:14:45 -0400 >> From: rcolebur at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> >> >> >> >> >> >> Olaf: >> >> >> >> Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. >> >> >> >> I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. >> >> >> >> I'll try to work on this tonight. >> >> >> >> Thanks for getting us to this stage in the process! >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Olaf Wagner 7/15/2009 2:31 AM>>> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> .. From jay.krell at cornell.edu Wed Jul 15 20:37:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 18:37:10 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: Definitely these should be renamed from what they are. Does "kext" bother anyone else, enough to come up with another name? kext is the extension for "kernel extensions" on Darwin -- drivers. Maybe I can get one more change in in the day window. :) Or it can be in after the RC, ok. It's a very compatible and fairly desirable change, to shorten the symlink chain lengths. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 19:35:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > OK< I've done the first changes to RC2 myself now:-/ > > cvs commit -m 'consistently rename programs lex, yacc, tok, ext to > klex, kyacc, ktok, kext' caltech-parser > > The following files have been changed: > T caltech-parser/parserlib/kext/src/m3makefile > T caltech-parser/parserlib/klex/src/m3makefile > T caltech-parser/parserlib/ktok/src/m3makefile > T caltech-parser/parserlib/kyacc/src/m3makefile > T caltech-parser/parserlib/parserlib/src/parser.tmpl > > I think that change is justified as we do not want to ship competing > yaccs and lexs again, that's rather surprising (not to say annoying). > > I'd suggest we'll wait another day for late fixes and then build > the RC2 packages. > Any comments/suggestions so far? > > Olaf > > Quoting Jay K : > >> I'd still like to: >> >> reduce the indirection in the recently introduced symlinks..it is >> a small change (that's what I always say!) (though the movement from >> pkg to lib I wouldn't call small) >> >> >> improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, >> AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, >> AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others >> >> These might be be mostly just: >> - updating RTSignalC.c >> - updating the GNU configuration name for AMD64_SOLARIS in >> m3cc/src/m3makefile >> - fix my Python scripts to consume the master package list, >> build m3gdb, build cm3ide, build in dependency order (huh, I thought >> they always did, now not sure), add your feature of passing on >> extra parameteres to cm3 >> - maybe change the *.sh files to accept parameters in any order >> like the *.py >> - maybe whittle away more on m3core/src/unix >> >> Also some minor features I'll propose shortly. >> >> - Jay >> >> >> >> >> >> >> >> ---------------------------------------- >>> Date: Wed, 15 Jul 2009 11:33:56 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; m3-support at elego.de >>> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>> >>> Quoting Jay K : >>> >>>> How does one checkout, update or commit to RC2 and beyond RC2? >>> >>> No changes here. I'd just like to avoid branching for the release, >>> and concentrate work on it. >>> >>>> There is still maybe the formsedit crash. I'll verify soon. >>>> >>>> Ideally we get to a situation in which distributions are built every >>>> day and what we ship is merely picked among them. I need to ever >>>> get Tinderbox working and under cron or in a loop. >>>> >>>> I also wonder if we should go back to 5.7.something, since we burned >>>> through 5.7 fairly fast. >>> >>> Please, let's just provide one stable official release, and not confuse >>> anybody by using old version numbers. >>> >>> Olaf >>> >>>> ---------------------------------------- >>>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> CC: m3-support at elego.de >>>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>>> >>>>> Hi all, >>>>> >>>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>>> The reported compiler vesion will be d5.8.2 for this RC. >>>>> There seems to be a neverending stream of commits, which makes >>>>> it quite difficult to choose a good time to do this, but I hope >>>>> that Tinderbox will show no major problems with the tagged sources. >>>>> >>>>> I'd like everybody for the next weeks to postpone their functional >>>>> changes and concentrate on testing and fixing bugs that are found >>>>> or already known. If anybody knows of any problems with the current >>>>> tag we can still move it in places _before_ we build any release >>>>> archives. Tagging the whole repository is a quite costly operation >>>>> in CVS. >>>>> >>>>> To summarize: >>>>> >>>>> o refrain from functional changes >>>>> o report and correct bugs >>>>> o don't build any distribution archives until we've agreed we've >>>>> tagged a good source set >>>>> >>>>> I'll perform some testing myself and try to prepare a draft for the >>>>> release notes (a lot of changes occured in the recent years) within the >>>>> next days. >>>>> >>>>> Thanks for your patience and your contribution, >>>>> >>>>> Olaf >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 15 21:08:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 15 Jul 2009 12:08:28 -0700 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: I meant to say from what they *were*. I only have to whine non zero about 'kext' I don't insist or such. What they *are* is fine. I was agreeing but accidentally disagreed. - oops (phone) On Jul 15, 2009, at 11:37 AM, Jay K wrote: > > Definitely these should be renamed from what they are. > Does "kext" bother anyone else, enough to come up with another name? > kext is the extension for "kernel extensions" on Darwin -- drivers. > > Maybe I can get one more change in in the day window. :) Or it can > be in after the RC, ok. It's a very compatible and fairly desirable > change, to shorten the symlink chain lengths. > > - Jay > > > ---------------------------------------- >> Date: Wed, 15 Jul 2009 19:35:01 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> OK< I've done the first changes to RC2 myself now:-/ >> >> cvs commit -m 'consistently rename programs lex, yacc, tok, ext to >> klex, kyacc, ktok, kext' caltech-parser >> >> The following files have been changed: >> T caltech-parser/parserlib/kext/src/m3makefile >> T caltech-parser/parserlib/klex/src/m3makefile >> T caltech-parser/parserlib/ktok/src/m3makefile >> T caltech-parser/parserlib/kyacc/src/m3makefile >> T caltech-parser/parserlib/parserlib/src/parser.tmpl >> >> I think that change is justified as we do not want to ship competing >> yaccs and lexs again, that's rather surprising (not to say annoying). >> >> I'd suggest we'll wait another day for late fixes and then build >> the RC2 packages. >> Any comments/suggestions so far? >> >> Olaf >> >> Quoting Jay K : >> >>> I'd still like to: >>> >>> reduce the indirection in the recently introduced symlinks..it is >>> a small change (that's what I always say!) (though the movement from >>> pkg to lib I wouldn't call small) >>> >>> >>> improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, >>> AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, >>> AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others >>> >>> These might be be mostly just: >>> - updating RTSignalC.c >>> - updating the GNU configuration name for AMD64_SOLARIS in >>> m3cc/src/m3makefile >>> - fix my Python scripts to consume the master package list, >>> build m3gdb, build cm3ide, build in dependency order (huh, I thought >>> they always did, now not sure), add your feature of passing on >>> extra parameteres to cm3 >>> - maybe change the *.sh files to accept parameters in any order >>> like the *.py >>> - maybe whittle away more on m3core/src/unix >>> >>> Also some minor features I'll propose shortly. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 11:33:56 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com; m3-support at elego.de >>>> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Quoting Jay K : >>>> >>>>> How does one checkout, update or commit to RC2 and beyond RC2? >>>> >>>> No changes here. I'd just like to avoid branching for the release, >>>> and concentrate work on it. >>>> >>>>> There is still maybe the formsedit crash. I'll verify soon. >>>>> >>>>> Ideally we get to a situation in which distributions are built >>>>> every >>>>> day and what we ship is merely picked among them. I need to ever >>>>> get Tinderbox working and under cron or in a loop. >>>>> >>>>> I also wonder if we should go back to 5.7.something, since we >>>>> burned >>>>> through 5.7 fairly fast. >>>> >>>> Please, let's just provide one stable official release, and not >>>> confuse >>>> anybody by using old version numbers. >>>> >>>> Olaf >>>> >>>>> ---------------------------------------- >>>>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: m3devel at elegosoft.com >>>>>> CC: m3-support at elego.de >>>>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>>>> The reported compiler vesion will be d5.8.2 for this RC. >>>>>> There seems to be a neverending stream of commits, which makes >>>>>> it quite difficult to choose a good time to do this, but I hope >>>>>> that Tinderbox will show no major problems with the tagged >>>>>> sources. >>>>>> >>>>>> I'd like everybody for the next weeks to postpone their >>>>>> functional >>>>>> changes and concentrate on testing and fixing bugs that are found >>>>>> or already known. If anybody knows of any problems with the >>>>>> current >>>>>> tag we can still move it in places _before_ we build any release >>>>>> archives. Tagging the whole repository is a quite costly >>>>>> operation >>>>>> in CVS. >>>>>> >>>>>> To summarize: >>>>>> >>>>>> o refrain from functional changes >>>>>> o report and correct bugs >>>>>> o don't build any distribution archives until we've agreed we've >>>>>> tagged a good source set >>>>>> >>>>>> I'll perform some testing myself and try to prepare a draft for >>>>>> the >>>>>> release notes (a lot of changes occured in the recent years) >>>>>> within the >>>>>> next days. >>>>>> >>>>>> Thanks for your patience and your contribution, >>>>>> >>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>> Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz >>>> : Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be >> rlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> From eiserlohpp at yahoo.com Thu Jul 16 03:19:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 15 Jul 2009 18:19:49 -0700 (PDT) Subject: [M3devel] M3Config contains paths to installation directory. Message-ID: <645960.77867.qm@web56801.mail.re3.yahoo.com> Hi Jay, Do you know of any way to tell the build system that the final installation directory is located in one place, but that the software is to actually be shipped (temporarily) to a staging directory. Specifically, libm3/src/config contains a m3makefile that derives the M3Config interface, containing a number of paths to the installation root directory. This is the normal situation for most people, but I am installing to a temporary directory, for packaging purposes. The packaging software later installs the package into the correct location. Whenever I build the system, M3Config always contains the paths to my staging area. I would like some way of specifying to the build system that the final (or real) installation root is one thing, but "ship" would actually install into a different one. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Thu Jul 16 04:46:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 02:46:35 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: 1) I do wonder if this is what PKG_USE vs. PKG_INSTALL is but not sure. 2) You can achieve your goal easily anyway? Like, stick -R/usr/local/lib in the right place? Appropriately generalized? That is -- introduce another variable, DESTDIR? I content that we have significant/complete control of all the config files, so you can feel able to go into m3-sys/cminstall/src/config-no-install and sprinkle like DESTDIR="/usr/local/cm3" into all the files, or just into cm3cfg.common. 3) Can you just avoid knowing it? > libm3/src/config Hm. Maybe we examine it, deem it "problematic", and reduce or remove its functionality, such as to eliminate your problem? Assume there aren't many users and watch for the fallout? Or maybe, and again, I have to look at it, but maybe whatever data is exposed here can be computed at runtime instead of build-time, assuming dynamic linking to libm3core.so? In Windows it is easy enough for some code at runtime to gets the path to the file (.exe, .dll) it is in. Other systems? So I think, using that, this interface can generate the data at runtime instead of build-time. Which may or maybe be what you want -- the "official " or "default" install location, or the actual "current" location? - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 18:19:49 -0700 > From: eiserlohpp at yahoo.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] M3Config contains paths to installation directory. > > > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Thu Jul 16 05:25:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 03:25:48 +0000 Subject: [M3devel] how to port to new target Message-ID: "how to port" I know there is a web already but maybe it needs updating. (Maybe not, basically just one item stricken/reduced). Based on the AMD64_NETBSD/OPENBSD work (ChangeLog entry), and /assuming/ gcc has already been ported, here is a/the specific current list of files that need visiting for porting: add a file to m3-sys/cminstall/src/config-no-install m3-sys/m3middle/src/Target.m3 m3-sys/m3middle/src/Target.i3 (trivial, just add to the list) m3-libs/m3core/src/runtime/common/Compiler.tmpl (trivial) add m3-libs/m3core/src/C/TARGET/Csetjmp.i3 (redundant with Target.m3) add m3-libs/m3core/src/C/TARGET/m3makefile (trivial, always the same) all these trivial: m3-libs/m3core/src/thread.quake m3-libs/libm3/src/os/POSIX/m3makefile m3-libs/libm3/src/random/m3makefile m3-libs/m3core/src/C/Common/m3makefile m3-libs/m3core/src/Csupport/m3makefile m3-libs/m3core/src/float/m3makefile m3-libs/m3core/src/runtime/m3makefile m3-libs/m3core/src/runtime/POSIX/m3makefile m3-libs/m3core/src/runtime/common/m3makefile m3-libs/m3core/src/time/POSIX/m3makefile m3-libs/m3core/src/unix/Common/m3makefile plus off the top of my head: scripts/sysinfo.sh -- platform detection using uname etc. scripts/python/pylib.py -- platform detection and possible changes to "boot" (redundant with config file sorry) m3-sys/m3cc/src/m3makefile -- at least add the TARGET => GNU_PLATFORM mapping for building a cross compiler; sometimes more is needed m3-sys/m3gdb/src/m3makefile -- ditto m3-libs/m3core/src/runtime/POSIX/RTSignalC.c for adding a new processor for Solaris or NetBSD, maybe already portable, but otherwise this file is highly target specific, though you can also just fallback and return 0. I'd rather not put in the fallback, lest porters don't get a "reminder". They can always make it so upon being reminded. (The reminder comes unfortunately late -- when native building the boot archive on the target platform.) plus some possible revisitation of: m3-libs/m3core/src/unix/Common but often just works. Adding a new processor for Darwin is a little different than other platforms. Threading is a little different, in a good way and you might to use Apple's fork of gcc (see m3cc/m3makefile, look for ARM_DARWIN). In future maybe things go a little different, like if there are more builtin backends or stack walkers. (Though I'm hoping for a fairly portable stack walker using libgcc/libunwind.) It should be possible to significantly reduce this if you are only adding another processor for an existing OS, or just another OS for existing processor. A lot of the checks only depend on endian or OS. Granted it is not a long list asis. If there is non-Posix non-NT platform, more work. - Jay From rodney.m.bates at cox.net Thu Jul 16 02:30:14 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 15 Jul 2009 19:30:14 -0500 Subject: [M3devel] Release notes comments Message-ID: <4A5E7496.7020308@cox.net> A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. From wagner at elegosoft.com Thu Jul 16 08:24:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 08:24:22 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <4A5E7496.7020308@cox.net> References: <4A5E7496.7020308@cox.net> Message-ID: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Quoting "Rodney M. Bates" : > A couple of comments on the release notes for 5.8.2:
  • System > pthread threading is now the default on all > platforms. The original (fast) M3 user level thread code is > still there and can be used if necessary (on most platforms). On > many systems, this allows M3 applications to scale over all > available hardware processors.
  • > > This sounds like it is the original user level threads that allow > scaling over multiple processors, which I believe is backwards. I > suggest swapping the second and third sentences be for clarity. >
  • New data type LONGINT (64 bit integer) on all target > platforms except Windows (still in the queue).
  • > > As I understand it, LONGINT is in Windows too, it just isn't 64 > bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 16 08:44:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 08:44:14 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> Please remind me again what exactly depends on this interface and why we do it that way. In cm3 I find quake variables like these (* Default to a native build, so the config file can say less. *) Quake.Define(mach, "TARGET", M3Config.TARGET); Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); Quake.Define(mach, "BACKEND_MODE", Version.BackendMode); Quake.Define(mach, "C_COMPILER", Version.CCompiler); Quake.Define(mach, "LINKER", Version.Linker); Quake.Define(mach, "THREAD_LIBRARY", Version.ThreadLibrary); Quake.Define(mach, "WINDOW_LIBRARY", Version.WindowLibrary); Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); (* Even if the config file overrides the defaults, such as to do a cross build, the host characteristics are still available. *) Quake.Define(mach, "HOST", M3Config.TARGET); Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); but no installation paths. Most code uses MxConfig AS M3Config. I see it's used in m3browser as package_root deault, but that can surely be fixed and it can also be specified on the command line. Same in m3tohtml. So why is it needed? One obvious way to overcome Peter's problem would of course be to pass a parameter block to quake when building ("m3config-overrides"?). Better perhaps to get rid of these paths. Olaf Quoting Peter Eiserloh : > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 16 09:43:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 07:43:22 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> Message-ID: I'm pretty confident we can fix this fairly soon. Many M3Config users can/should be replaced with MxConfig. MxConfig can be augmented with "static" things like OS_TYPE, PATH_SEP. Capturing stuff like PKG_USE at compile time is quite bogus, except as part of some sort of "cm3 -v" like how gcc reports its configure command line. But that wouldn't be in a public interface. Can anyone confirm the theory I just invented as to the history here? M3Config existed. M3Config was recognized as broken. MxConfig introduced as a replacement for M3Config. This "AS" construct I see used rarely, makes me thing something a little unusual afoot here, and "getting something very wrong the first time" seems to be unusual in M3. :) Doing the same grep that Olaf did... C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(177): CopyTextArray(self.options.addSearchDir,M3Config.PKG_USE & broken C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(178): M3Config.PATH_SEP & "sgml" & M3Config.PATH_SEP & "src" & C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(179): M3Config.PATH_SEP & "dtd"); ok, augment MxConfig with this data C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(57): env := NewEnv("target", NewText(M3Config.TARGET), env); C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(58): env := NewEnv("osType", NewText(M3Config.OS_TYPE), env); C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(59): env := NewEnv("pathSep", NewText(M3Config.PATH_SEP), env); ditto C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, "TARGET", M3Config.TARGET); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, "HOST", M3Config.TARGET); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); I put all these in and they are all ok, but also ditto. (The idea being we end up with only MxConfig and no M3Config.) C:\dev2\cm3.2\m3-sys\cm3ide\src\misc\Default.m3(35): build_dir := M3Config.Get ("BUILD_DIR"); C:\dev2\cm3.2\m3-sys\cm3ide\src\misc\Default.m3(36): system_root := M3Config.Get ("PKG_USE"); (* note: system_root is the public package root *) These are all really MxConfig, everything in this file, ok. C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(22): SLASH = M3Config.PATH_SEP; ok C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(31): package_root := M3Config.PKG_USE; broken C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(37): derived_dirs := IntList.List1 (ID.Add (M3Config.BUILD_DIR)); slightly broken C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(137): pkgRoot := M3Config.PKG_USE; broken C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(243): proj_pkg := pkgRoot & M3Config.PATH_SEP & pkg; ok C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(281): IF Text.GetChar (filename, i) # Text.GetChar (M3Config.BUILD_DIR, i) THEN slightly broken, BUILD_DIR is not necessarily TARGET, though if/when we provide CM3_OUTPUT_ROOT, BUILD_DIR can go away, or just be really synonymous with TARGET. C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(287): IF Text.GetChar (filename, i) = Text.GetChar (M3Config.PATH_SEP, 0) THEN ok C:\dev2\cm3.2\m3-tools\m3tohtml\src\Msg.m3(38): IF Text.Equal(M3Config.OS_TYPE, "WIN32") THEN ok, but there is a better way, something like Wr.EOL or OSConfig.LineSep, which are completely redundant, and Wr.EOL ideally would be a constant. later.. - Jay > Date: Thu, 16 Jul 2009 08:44:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > Please remind me again what exactly depends on this interface > and why we do it that way. > > In cm3 I find quake variables like these > > (* Default to a native build, so the config file can say less. *) > > Quake.Define(mach, "TARGET", M3Config.TARGET); > Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); > Quake.Define(mach, "BACKEND_MODE", Version.BackendMode); > Quake.Define(mach, "C_COMPILER", Version.CCompiler); > Quake.Define(mach, "LINKER", Version.Linker); > Quake.Define(mach, "THREAD_LIBRARY", Version.ThreadLibrary); > Quake.Define(mach, "WINDOW_LIBRARY", Version.WindowLibrary); > Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); > > (* Even if the config file overrides the defaults, such as to do > a cross build, the host characteristics are still available. *) > > Quake.Define(mach, "HOST", M3Config.TARGET); > Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); > Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); > > but no installation paths. Most code uses MxConfig AS M3Config. > > I see it's used in m3browser as package_root deault, but that can surely > be fixed and it can also be specified on the command line. > Same in m3tohtml. So why is it needed? > > One obvious way to overcome Peter's problem would of course be > to pass a parameter block to quake when building ("m3config-overrides"?). > Better perhaps to get rid of these paths. > > Olaf > > Quoting Peter Eiserloh : > > > Hi Jay, > > > > Do you know of any way to tell the build system that the > > final installation directory is located in one place, but > > that the software is to actually be shipped (temporarily) > > to a staging directory. > > > > Specifically, libm3/src/config contains a m3makefile that > > derives the M3Config interface, containing a number of > > paths to the installation root directory. > > > > This is the normal situation for most people, but I am > > installing to a temporary directory, for packaging purposes. > > The packaging software later installs the package into > > the correct location. > > > > Whenever I build the system, M3Config always contains > > the paths to my staging area. > > > > I would like some way of specifying to the build system > > that the final (or real) installation root is one thing, > > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh | > > +--------------------------------------------------------+ > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 16 14:57:05 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 14:57:05 +0200 Subject: [M3devel] how to port to new target In-Reply-To: References: Message-ID: <20090716145705.vc4lzxbu8oo8kskk@mail.elegosoft.com> How about updating http://www.opencm3.net/porting.html? This mail will be much more difficult to find later... Olaf Quoting Jay K : > "how to port" > > I know there is a web already but maybe it needs updating. (Maybe > not, basically just one item stricken/reduced). > > > Based on the AMD64_NETBSD/OPENBSD work (ChangeLog entry), and /assuming/ > gcc has already been ported, here is a/the specific > current list of files that need visiting for porting: > > > add a file to m3-sys/cminstall/src/config-no-install > m3-sys/m3middle/src/Target.m3 > m3-sys/m3middle/src/Target.i3 (trivial, just add to the list) > m3-libs/m3core/src/runtime/common/Compiler.tmpl (trivial) > > > add m3-libs/m3core/src/C/TARGET/Csetjmp.i3 (redundant with Target.m3) > add m3-libs/m3core/src/C/TARGET/m3makefile (trivial, always the same) > > > all these trivial: > m3-libs/m3core/src/thread.quake > m3-libs/libm3/src/os/POSIX/m3makefile > m3-libs/libm3/src/random/m3makefile > m3-libs/m3core/src/C/Common/m3makefile > m3-libs/m3core/src/Csupport/m3makefile > m3-libs/m3core/src/float/m3makefile > m3-libs/m3core/src/runtime/m3makefile > m3-libs/m3core/src/runtime/POSIX/m3makefile > m3-libs/m3core/src/runtime/common/m3makefile > m3-libs/m3core/src/time/POSIX/m3makefile > m3-libs/m3core/src/unix/Common/m3makefile > > > plus off the top of my head: > scripts/sysinfo.sh -- platform detection using uname etc. > scripts/python/pylib.py -- platform detection and possible changes > to "boot" (redundant with config file sorry) > m3-sys/m3cc/src/m3makefile -- at least add the TARGET => GNU_PLATFORM > mapping for building a cross compiler; sometimes more is needed > m3-sys/m3gdb/src/m3makefile -- ditto > m3-libs/m3core/src/runtime/POSIX/RTSignalC.c > for adding a new processor for Solaris or NetBSD, maybe already portable, > but otherwise this file is highly target specific, though you can > also just fallback and return 0. > I'd rather not put in the fallback, > lest porters don't get a "reminder". > They can always make it so upon being reminded. > (The reminder comes unfortunately late -- when native building > the boot archive on the target platform.) > > > plus some possible revisitation of: > m3-libs/m3core/src/unix/Common but > often just works. > > > Adding a new processor for Darwin is a > little different than other platforms. > Threading is a little different, in a good > way and you might to use Apple's fork of gcc (see > m3cc/m3makefile, look for ARM_DARWIN). > > > In future maybe things go a little different, > like if there are more builtin backends > or stack walkers. (Though I'm hoping for > a fairly portable stack walker using libgcc/libunwind.) > > > It should be possible to significantly reduce > this if you are only adding another processor > for an existing OS, or just another > OS for existing processor. > > > A lot of the checks only depend on endian or OS. > Granted it is not a long list asis. > > > If there is non-Posix non-NT platform, more work. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 16 15:05:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 15:05:58 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I meant to say from what they *were*. I only have to whine non zero > about 'kext' I don't insist or such. What they *are* is fine. I was > agreeing but accidentally disagreed. I thought as much. > - oops (phone) > > On Jul 15, 2009, at 11:37 AM, Jay K wrote: > >> Definitely these should be renamed from what they are. >> Does "kext" bother anyone else, enough to come up with another >> name? kext is the extension for "kernel extensions" on Darwin -- >> drivers. I didn't think of that, but I don't think it matters; there is no program named kext on Darwin, is there? >> Maybe I can get one more change in in the day window. :) Or it can >> be in after the RC, ok. It's a very compatible and fairly desirable >> change, to shorten the symlink chain lengths. If it's easy and won't break anything, go ahead. I'd like to build some packages by the end of this week. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Jul 16 16:39:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Jul 2009 10:39:03 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Message-ID: <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non- optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> A couple of comments on the release notes for 5.8.2:
  • System >> pthread threading is now the default on all >> platforms. The original (fast) M3 user level thread code is >> still there and can be used if necessary (on most platforms). On >> many systems, this allows M3 applications to scale over all >> available hardware processors.
  • >> >> This sounds like it is the original user level threads that allow >> scaling over multiple processors, which I believe is backwards. I >> suggest swapping the second and third sentences be for clarity. >>
  • New data type LONGINT (64 bit integer) on all target >> platforms except Windows (still in the queue).
  • >> >> As I understand it, LONGINT is in Windows too, it just isn't 64 >> bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for > several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least > some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in > source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 16 19:39:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 16 Jul 2009 13:39:29 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090630175228.GA16767@topoi.pooq.com> References: <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> <20090630175228.GA16767@topoi.pooq.com> Message-ID: <20090716173929.GB9087@topoi.pooq.com> On Tue, Jun 30, 2009 at 01:52:28PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: > > > > If it now just works and the problem cannot be reproduced, we should > > leave it that way. I wouldn't invest much time on chasing down such > > a spurious error now. > > OK. I'll take a look at installation instructions for some of the other > packages, such as the one with Trestle. > > -- hendrik Installed the collection m3gdb from archive cm3-bin-ws-m3gdb-LINUXLIBC6-d5.8.1-RC1.tgz; it installed flawlessly on Debian squeeze (32-bit intel). Did the same for m3gui, had a glitch. It's at the end of the shell log below. I've provided the entire log, starting with untarring the archive, in case you need context. -- hendrik hendrik at notlookedfor:~/cm3/collection-gui$ tar -zxf cm3-bin-ws-gui-LINUXLIBC6-d5.8.1-RC1.tgz hendrik at notlookedfor:~/cm3/collection-gui$ ls cm3-bin-ws-gui-LINUXLIBC6-d5.8.1-RC1.tgz install.sh m3-tools m3-win collection-gui.html m3-comm m3-ui hendrik at notlookedfor:~/cm3/collection-gui$ ./install.sh --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 .M3EXPORTS libm3tcp.so.5 libm3tcp.so libm3tcp.a libm3tcp.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/tcp/src/POSIX TCP.m3 TCPPosix.i3 Herrno.i3 HerrnoC.c IP.m3 IPErrorPosix.m3 TCPExtras.m3 TCPPeer.m3 TCPHack.i3 TCPHackNull.m3 ../src/common => /usr/local/cm3/pkg/tcp/src/common TCP.i3 IP.i3 TCPExtras.i3 TCPPeer.i3 IPError.i3 IPError.m3 StreamRd.i3 StreamRdClass.m3 StreamRdClass.i3 StreamWr.i3 StreamWrClass.i3 StreamWrClass.m3 TCPSpecial.i3 TCPMisc.i3 ConnFD.i3 ConnRW.i3 ConnRW.m3 ConnMsgRW.i3 ConnMsgRW.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/X11R4/LINUXLIBC6 .M3EXPORTS libm3X11R4.so.5 libm3X11R4.a libm3X11R4.m3x .M3WEB ../src/Vanilla => /usr/local/cm3/pkg/X11R4/src/Vanilla XMachine.i3 ../src/Common => /usr/local/cm3/pkg/X11R4/src/Common X.i3 Xatom.i3 Xmbuf.i3 Xct.i3 Xmu.i3 Xrm.i3 Xt.i3 XtC.m3 XtC.i3 XtE.i3 XtE.m3 XtN.i3 XtN.m3 XtR.i3 XtR.m3 Xaw.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/ui/LINUXLIBC6 .M3EXPORTS libm3ui.so.5 libm3ui.a libm3ui.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/ui/LINUXLIBC6 ComplSeq.i3 ComplSeq.m3 ComplSeqRep.i3 STypeMapSeq.m3 STypeMapSeq.i3 STypeMapSeqRep.i3 CompletionSeq.m3 CompletionSeq.i3 CompletionSeqRep.i3 ../src/xvbt => /usr/local/cm3/pkg/ui/src/xvbt Compl.i3 Compl.m3 XExtensions.i3 XExtensions.m3 XImUtil.i3 TrslOnXF.i3 XShm.i3 XClientExt.i3 XPicture.m3 XPicture.i3 XSharedMem.i3 XSharedMem.m3 XPictureFree.m3 XSharedFree.m3 PictureImpl.m3 XClient.m3 XClient.i3 XEventQueue.i3 XEventQueue.m3 XScreenType.i3 XScreenType.m3 XScrollQueue.m3 XScrollQueue.i3 XAtomQueue.m3 XAtomQueue.i3 XMessenger.i3 XMessenger.m3 XPaint.i3 XPaint.m3 XInput.i3 XInput.m3 XProperties.i3 XProperties.m3 XClientF.i3 XClientF.m3 XGC.m3 XGC.i3 XScrnTpRep.i3 XScrnTpRep.m3 XScrnCrsr.i3 XScrnCrsr.m3 XScrnCmap.m3 XScrnCmap.i3 XScrnFont.i3 XScrnFont.m3 XScrnPntOp.i3 XScrnPntOp.m3 XScrnPxmp.m3 XScrnPxmp.i3 XCursors.i3 XConfCtl.i3 XConfCtl.m3 TrestleOnX.i3 TrestleOnX.m3 TrestleOS.m3 ../src/vbt => /usr/local/cm3/pkg/ui/src/vbt Latin1Key.i3 KeyboardKey.i3 Trestle.i3 TrestleComm.i3 VBTTuning.i3 BatchRep.i3 PaintExt.i3 PlttFrnds.m3 PlttFrnds.i3 VBT.m3 VBT.i3 VBTClass.i3 VBTClass.m3 Batch.i3 Batch.m3 PaintPrivate.m3 PaintPrivate.i3 VBTRep.m3 VBTRep.i3 TrestleClass.m3 TrestleClass.i3 ScrnPixmap.m3 ScrnPixmap.i3 ScrnColorMap.i3 ScrnColorMap.m3 BatchUtil.i3 BatchUtil.m3 ScrnCursor.m3 ScrnCursor.i3 ScrnFont.i3 ScrnFont.m3 ScrnPaintOp.i3 ScrnPaintOp.m3 PaintOp.m3 PaintOp.i3 Palette.m3 Palette.i3 Font.i3 Font.m3 Cursor.i3 Cursor.m3 Pixmap.m3 Pixmap.i3 ScreenType.m3 ScreenType.i3 MouseSplit.m3 MouseSplit.i3 MiscDetail.m3 MiscDetail.i3 ../src/split => /usr/local/cm3/pkg/ui/src/split BtnVBTClass.i3 TextVBTClass.i3 BdrVBTClass.i3 STypeMap.i3 ComposeKey.m3 ComposeKey.i3 TranslateVBT.m3 TranslateVBT.i3 DblBufferVBT.i3 DblBufferVBT.m3 DblBufferUtil.m3 DblBufferUtil.i3 BorderedVBT.i3 BorderedVBT.m3 FilterClass.m3 FilterClass.i3 HVSplit.i3 HVSplit.m3 ZSplit.i3 ZSplit.m3 TSplit.i3 TSplit.m3 ButtonVBT.i3 ButtonVBT.m3 MenuBtnVBT.i3 MenuBtnVBT.m3 AnchorBtnVBT.i3 AnchorBtnVBT.m3 PackSplit.m3 PackSplit.i3 ProperSplit.i3 ProperSplit.m3 TextVBT.i3 TextVBT.m3 HVBar.i3 HVBar.m3 HighlightVBT.i3 HighlightVBT.m3 QuickBtnVBT.i3 QuickBtnVBT.m3 RigidVBT.m3 RigidVBT.i3 TextureVBT.i3 TextureVBT.m3 Split.i3 Split.m3 Filter.i3 Filter.m3 TypeInVBT.m3 TypeInVBT.i3 StableVBT.m3 StableVBT.i3 Gray.m3 Gray.i3 TwoTone.m3 TwoTone.i3 JoinedVBT.m3 JoinedVBT.i3 JoinParent.m3 JoinParent.i3 JoinScreen.i3 JoinScreen.m3 JoinCMap.m3 JoinCMap.i3 JoinCursor.i3 JoinCursor.m3 JoinFont.m3 JoinFont.i3 JoinPixmap.i3 JoinPixmap.m3 JoinPaintOp.i3 JoinPaintOp.m3 ETAgent.i3 ETAgent.m3 SelectQueue.m3 SelectQueue.i3 OverlayVBT.m3 OverlayVBT.i3 ../src/trestle => /usr/local/cm3/pkg/ui/src/trestle TrestleOS.i3 Trestle.m3 TrestleImpl.i3 InstallQueue.m3 InstallQueue.i3 DpyFilter.m3 DpyFilter.i3 TrestleGoo.i3 TrestleGoo.m3 InstalledVBT.i3 InstalledVBT.m3 TrestleConf.i3 ../src/picture => /usr/local/cm3/pkg/ui/src/picture Completion.m3 Completion.i3 Picture.m3 Picture.i3 PictureRep.i3 FreeList.mg --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/vbtkit/LINUXLIBC6 .M3EXPORTS libm3vbtkit.so.5 libm3vbtkit.a libm3vbtkit.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/vbtkit/LINUXLIBC6 VBTKitBundle.i3 VBTKitBundle.m3 ../src/lego/POSIX => /usr/local/cm3/pkg/vbtkit/src/lego/POSIX ScrollerVBTClass.m3 ZChassisVBT.m3 ../src/lego => /usr/local/cm3/pkg/vbtkit/src/lego AnchorSplit.i3 AnchorSplit.m3 AnchorHelpSplit.i3 AnchorHelpSplit.m3 AnchorHelpVBT.i3 AnchorHelpVBT.m3 BiFeedbackVBT.i3 BiFeedbackVBT.m3 BooleanVBT.i3 BooleanVBT.m3 ChoiceVBT.m3 ChoiceVBT.i3 FeedbackVBT.m3 FeedbackVBT.i3 FileBrowserVBT.i3 FileBrowserVBT.m3 FlexVBT.i3 FlexVBT.m3 GuardedBtnVBT.i3 GuardedBtnVBT.m3 Image.m3 Image.i3 ListVBT.i3 ListVBT.m3 MarginFeedbackVBT.i3 MarginFeedbackVBT.m3 MenuSwitchVBT.i3 MenuSwitchVBT.m3 MultiFilter.i3 MultiFilter.m3 MultiSplit.i3 MultiSplit.m3 MultiClass.i3 MultiClass.m3 NumericVBT.i3 NumericVBT.m3 OffsetVBT.i3 OffsetVBT.m3 PixmapVBT.i3 PixmapVBT.m3 QuickSwitchVBT.i3 QuickSwitchVBT.m3 ReactivityVBT.i3 ReactivityVBT.m3 ScaleFilter.i3 ScaleFilter.m3 ScrollerVBT.i3 ScrollerVBT.m3 ScrollerVBTClass.i3 Shadow.i3 Shadow.m3 ShadowPaint.i3 ShadowPaint.m3 ShadowedBarVBT.i3 ShadowedBarVBT.m3 ShadowedFeedbackVBT.m3 ShadowedFeedbackVBT.i3 ShadowedVBT.m3 ShadowedVBT.i3 SourceVBT.i3 SourceVBT.m3 SplitterVBT.i3 SplitterVBT.m3 SwitchVBT.i3 SwitchVBT.m3 TrillSwitchVBT.i3 TrillSwitchVBT.m3 VBTKitResources.i3 VBTKitResources.m3 ViewportVBT.i3 ViewportVBT.m3 ZBackgroundVBT.i3 ZBackgroundVBT.m3 ZChassisVBT.i3 ZChildVBT.i3 ZChildVBT.m3 ZGrowVBT.i3 ZGrowVBT.m3 ZMoveVBT.i3 ZMoveVBT.m3 ZSplitUtils.i3 ZSplitUtils.m3 ZTilps.i3 ZTilps.m3 ../src/vbtkitutils/POSIX => /usr/local/cm3/pkg/vbtkit/src/vbtkitutils/POSIX VBTKitEnv.i3 ../src/vbtkitutils => /usr/local/cm3/pkg/vbtkit/src/vbtkitutils AnyEvent.m3 AnyEvent.i3 AutoRepeat.i3 AutoRepeat.m3 LargeCursor.i3 LargeCursor.m3 Pts.i3 Pts.m3 Rsrc.i3 Rsrc.m3 VBTColors.i3 VBTColors.m3 VBTKitEnv.m3 XParam.m3 XParam.i3 XTrestle.i3 XTrestle.m3 ../src/etext => /usr/local/cm3/pkg/vbtkit/src/etext ISOChar.i3 ISOChar.m3 Key.i3 Key.m3 KeyFilter.m3 KeyFilter.i3 KeyTrans.i3 KeyTrans.m3 MTextUnit.i3 MTextUnit.m3 TextEditVBT.i3 TextEditVBT.m3 TextPort.i3 TextPort.m3 TextPortClass.m3 TextPortClass.i3 TypeinVBT.i3 TypeinVBT.m3 TypescriptVBT.i3 TypescriptVBT.m3 IvyModel.m3 IvyModel.i3 EmacsModel.i3 EmacsModel.m3 XtermModel.i3 XtermModel.m3 MacModel.m3 MacModel.i3 ../src/vtext => /usr/local/cm3/pkg/vbtkit/src/vtext VTDef.i3 VTextDef.i3 VText.i3 VText.m3 VT.i3 VT.m3 VTBase.i3 VTBase.m3 VTCaret.m3 VTCaret.i3 VTInterval.i3 VTInterval.m3 VTMarker.i3 VTMarker.m3 VTPounce.m3 VTPounce.i3 VTRd.i3 VTRd.m3 VTReal.i3 VTReal.m3 VTTexture.m3 VTTexture.i3 VTView.i3 VTView.m3 VTVirtual.i3 VTVirtual.m3 VTextRegion.m3 VTextRegion.i3 ../src/mtext => /usr/local/cm3/pkg/vbtkit/src/mtext MText.i3 MText.m3 MTextRd.i3 MTextRd.m3 MTextPrivate.i3 MTextDs.i3 MTextDs.m3 MTextDebug.i3 MTextDebug.m3 ../src/color => /usr/local/cm3/pkg/vbtkit/src/color Color.m3 Color.i3 ColorName.i3 ColorName.m3 ColorNameF.i3 ColorNameTable.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/cmvbt/LINUXLIBC6 .M3EXPORTS libcmvbt.so.5 libcmvbt.a libcmvbt.m3x .M3WEB ../src => /usr/local/cm3/pkg/cmvbt/src IntervalTimer.i3 IntervalTimer.m3 TabVBT.i3 TabVBT.m3 IPTypeinVBT.m3 IPTypeinVBT.i3 FrameVBT.i3 FrameVBT.m3 HoverVBT.i3 HoverVBT.m3 PasswordFont.m3 PasswordFont.i3 GridSplit.i3 GridSplit.m3 TableVBT.i3 TableVBT.m3 SortedTableVBT.m3 SortedTableVBT.i3 AnimateVBT.i3 AnimateVBT.m3 ClockVBT.i3 ClockVBT.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/jvideo/LINUXLIBC6 .M3EXPORTS libjvideo.so.5 libjvideo.a libjvideo.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/jvideo/src/POSIX JVBuffer.i3 JVSink.i3 Jv.i3 Jvs.m3 Jvs.i3 Jva.i3 Jva.m3 JvsProtocol.i3 JvaProtocol.i3 jvprotocol.i3 JvsBuffer.i3 JVFromSource.i3 JVFromSource.m3 JVFromDecomp.m3 JVFromDecomp.i3 JVConverter.m3 JVConverter.i3 JVConverterF.i3 JVDecomp.i3 JVDecomp.m3 JVAudio.i3 JVAudio.m3 JVSinkPool.m3 JVSinkPool.i3 JVDecompPool.i3 JVDecompPool.m3 ../src/POSIX/generic => /usr/local/cm3/pkg/jvideo/src/POSIX/generic JVBuffer.m3 JVSink.m3 Jv.m3 JvsBuffer.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/videovbt/LINUXLIBC6 .M3EXPORTS libvideovbt.so.5 libvideovbt.a libvideovbt.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/videovbt/src/POSIX AudioVBT.m3 VideoVBT.m3 VideoVBTRep.i3 ../src => /usr/local/cm3/pkg/videovbt/src AudioVBT.i3 VideoVBT.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsvbtpixmaps/LINUXLIBC6 .M3EXPORTS libm3formsvbtpixmaps.so.5 libm3formsvbtpixmaps.a libm3formsvbtpixmaps.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/formsvbtpixmaps/LINUXLIBC6 FormsVBTPixmapsBundle.i3 FormsVBTPixmapsBundle.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsvbt/LINUXLIBC6 .M3EXPORTS libm3formsvbt.so.5 libm3formsvbt.a libm3formsvbt.m3x .M3WEB ../src => /usr/local/cm3/pkg/formsvbt/src StubImages.i3 StubImageRd.i3 StubImageRd.m3 StubImageVBT.i3 StubImageVBT.m3 FVTypes.i3 FormsVBT.i3 FormsVBT.m3 FVRuntime.m3 FVRuntime.i3 Manpage.i3 Manpage.m3 Macro.i3 Macro.m3 RefListUtils.i3 RefListUtils.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsview/LINUXLIBC6 .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/formsview/src formsview.m3 . => /usr/local/cm3/pkg/formsview/LINUXLIBC6 formsview --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/man/man1 formsedit.1 . => /usr/local/cm3/pkg/formsedit/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/formsedit/LINUXLIBC6 formseditBundle.i3 formseditBundle.m3 ../src => /usr/local/cm3/pkg/formsedit/src FormsEditVBT.i3 FormsEditVBT.m3 FormsEdit.m3 . => /usr/local/cm3/bin formsedit --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/opengl/LINUXLIBC6 .M3EXPORTS libopengl.so.5 libopengl.a libopengl.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/opengl/src/POSIX GL.i3 GLX.i3 GLu.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/webvbt/LINUXLIBC6 .M3EXPORTS libwebvbt.so.5 libwebvbt.a libwebvbt.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/webvbt/LINUXLIBC6 ResourceBundle.i3 ResourceBundle.m3 CITextElementTbl.i3 CITextElementTbl.m3 TextPortButtonSeq.m3 TextPortButtonSeq.i3 TextPortButtonSeqRep.i3 ../src => /usr/local/cm3/pkg/webvbt/src CIText.m3 CIText.i3 Element.i3 Lexer.i3 Lexer.m3 HTML.i3 HTML.m3 HTMLParser.m3 HTMLVBT.i3 HTMLVBT.m3 HTMLVBTG.m3 HTMLVBTG.i3 HTMLVBTGRep.i3 Images.m3 Images.i3 ImageUtils.i3 ImageUtils.m3 Oblet.i3 SimpleWeb.m3 SimpleWeb.i3 URLCache.i3 URLCache.m3 WebVBT.i3 WebVBT.m3 HTMLVBTText.i3 HTMLVBTText.m3 TextPortButton.i3 TextPortButton.m3 TextPortWithButtons.i3 TextPortWithButtons.m3 ../src/oblet => /usr/local/cm3/pkg/webvbt/src/oblet Oblet.m3 ObLibWeb.m3 ObLibWeb.i3 --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. hendrik at notlookedfor:~/cm3/collection-gui$ From jay.krell at cornell.edu Thu Jul 16 20:41:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:41:52 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: Yes. These are subtle but true points. os = cygwin or mingwin or interix or nt but mingwin is really nt, this is clarified below ostype = win32 or posix but this maps directly from os so isn't a multiplicative factor fork = fast or slow or none also maps from os/runtime backend = gcc or integrated gcc backend BITSIZE(LONGINT)==64 integrated backend BITSIZE(LONGINT)==32 I386_CYGWIN (NT386GNU) Posix, slow fork gcc backend, BITSIZE(LONGINT)==64 I386_MINGWIN (NT386MINGNU) Win32, probably no fork (though in reality there some hybrid aspects, intended only for the use of the compiler/linker/etc., intended not to be injected into stuff you build) gcc backend, BITSIZE(LONGINT)==64 I386_INTERIX Posix, fast fork uses gcc backend, BITSIZE(LONGINT)==64 I386_NT (NT386) Win32, no fork integrated backend, BITSIZE(LONGINT)==32 Cygwin hangs in one of the test cases. Mingw had some major problem last I checked like crashing in all gui apps. More combinations than this make sense. You could use the integrated backend with Cygwin or Interix for example. Mingwin, you know, is meant to be NT386 with the gcc backend. Mingwin is not an OS or runtime. Three runtimes: Cygwin, Interix, NT two backends: integrated, gcc therefore 6 combinations of which 4 are named above Consider that integrated backend could be adapted for I386_LINUX, I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... - Jay From: hosking at cs.purdue.edu To: wagner at elegosoft.com Date: Thu, 16 Jul 2009 10:39:03 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non-optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: Quoting "Rodney M. Bates" : A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 20:52:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:52:25 +0000 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: ps: Interix in fact, outside of Modula-3, can use gcc or Visual C++. They have a cc wrapper that translates the command line and calls cl.exe. Not sure if both linkers are available -- you know, because Interix seems to have substantial support for stuff Visual C++ link.exe does not have -- runpath, $origin. As well, Cygwin/mingw/Visual C++ all use the same object file format and to a significant extent can link each other's output. So you can use Visual C++ with Cygwin, gcc without a cygwin dependency. They have/had a gcc -mnocygwin switch, though there is tension between "biarch" vs. "just separate targets". So, actually, in cm3, these are all the same "target", "NT386", just different config files. This was an experiment and I'm still feeling mixed about the results. They way it is constructed leaves it generally pretty easy to construct the combinations that aren't named. You don't have to change cm3 at all, nor I think any m3makefile, just the config file. Well, in the m3makefiles, in m3core, there is deciding on using pthreads or NT threads, since you can use NT threads with Posix cygwin. You know, look at how SOLgnu and SOLsun are implemented -- they are all identical except for the config files. Similar situation but in this case they were broken out into separate targets, and all the target-specific code is /identical/. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elegosoft.com Date: Thu, 16 Jul 2009 18:41:52 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Yes. These are subtle but true points. os = cygwin or mingwin or interix or nt but mingwin is really nt, this is clarified below ostype = win32 or posix but this maps directly from os so isn't a multiplicative factor fork = fast or slow or none also maps from os/runtime backend = gcc or integrated gcc backend BITSIZE(LONGINT)==64 integrated backend BITSIZE(LONGINT)==32 I386_CYGWIN (NT386GNU) Posix, slow fork gcc backend, BITSIZE(LONGINT)==64 I386_MINGWIN (NT386MINGNU) Win32, probably no fork (though in reality there some hybrid aspects, intended only for the use of the compiler/linker/etc., intended not to be injected into stuff you build) gcc backend, BITSIZE(LONGINT)==64 I386_INTERIX Posix, fast fork uses gcc backend, BITSIZE(LONGINT)==64 I386_NT (NT386) Win32, no fork integrated backend, BITSIZE(LONGINT)==32 Cygwin hangs in one of the test cases. Mingw had some major problem last I checked like crashing in all gui apps. More combinations than this make sense. You could use the integrated backend with Cygwin or Interix for example. Mingwin, you know, is meant to be NT386 with the gcc backend. Mingwin is not an OS or runtime. Three runtimes: Cygwin, Interix, NT two backends: integrated, gcc therefore 6 combinations of which 4 are named above Consider that integrated backend could be adapted for I386_LINUX, I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... - Jay From: hosking at cs.purdue.edu To: wagner at elegosoft.com Date: Thu, 16 Jul 2009 10:39:03 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non-optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: Quoting "Rodney M. Bates" : A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 20:54:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:54:59 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword Message-ID: We have some redundancies that are causing me some grief. We have two units called M3ID. They have no overlap, and could be merged into one. "No overlap" doesn't mean they are completely unrelated, but sort of. More bothersome is that m3-sys\m3scanner and m3-tools\m3scan have near duplicate code, in particular the list of tokens and the Classify function. In particular, where people were using libm3\M3Config, there are problems using instead m3quake\MxConfig, because this can bring together the two M3IDs. I was going to replace all uses of M3Config with MxConfig. However to avoid the duplicate M3ID units, I think I'll keep M3Config and MxConfig more like duplicates of each other at least for now, to avoid bringing m3quake into places that have the other M3ID. M3Config is in libm3 and MxConfig is in m3quake. m3quake imports m3middle, which has M3ID. Therefore, if you use M3Config and have your own M3ID, you can't switch to MxConfig without renaming one of the M3IDs. This does occur in m3-tools. C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(25):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): TK = C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(360): END Classify; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.i3(12):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.m3(17):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T = - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 21:08:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 19:08:23 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword In-Reply-To: References: Message-ID: I might be able to win just by making m3scan/m3id.i3 not public, changing Module to module in the m3makefile or such. Or renaming it, same thing really. The unit name only occurs twice. I have to verify nobody uses it outside of m3scan though. Keeping MxConfig/M3Config duplicates isn't great, because I have MxConfig importing M3Config's constants, and then M3Config would want to have a Get function that called into MxConfig -- circularity..though the constants are generated and that could be copied instead...not a lot of duplication here in any case but I'll see... - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Thu, 16 Jul 2009 18:54:59 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword We have some redundancies that are causing me some grief. We have two units called M3ID. They have no overlap, and could be merged into one. "No overlap" doesn't mean they are completely unrelated, but sort of. More bothersome is that m3-sys\m3scanner and m3-tools\m3scan have near duplicate code, in particular the list of tokens and the Classify function. In particular, where people were using libm3\M3Config, there are problems using instead m3quake\MxConfig, because this can bring together the two M3IDs. I was going to replace all uses of M3Config with MxConfig. However to avoid the duplicate M3ID units, I think I'll keep M3Config and MxConfig more like duplicates of each other at least for now, to avoid bringing m3quake into places that have the other M3ID. M3Config is in libm3 and MxConfig is in m3quake. m3quake imports m3middle, which has M3ID. Therefore, if you use M3Config and have your own M3ID, you can't switch to MxConfig without renaming one of the M3IDs. This does occur in m3-tools. C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(25):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): TK = C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(360): END Classify; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.i3(12):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.m3(17):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T = - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 16 21:47:13 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 16 Jul 2009 15:47:13 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <4A5E7496.7020308@cox.net> References: <4A5E7496.7020308@cox.net> Message-ID: <20090716194713.GA9452@topoi.pooq.com> On Wed, Jul 15, 2009 at 07:30:14PM -0500, Rodney M. Bates wrote: > A couple of comments on the release notes for 5.8.2: > >
  • System pthread threading is now the default on all > platforms. The original (fast) M3 user level thread code is > still there and can be used if necessary (on most platforms). On > many systems, this allows M3 applications to scale over all > available hardware processors.
  • > > This sounds like it is the original user level threads that allow > scaling over multiple processors, which I believe is backwards. > I suggest swapping the second and third sentences be for clarity. Actiually. the second sentence won't really work if it's moved to the start, since it seems to launch from the first one. Some rewording may be necessary as well as swapping. -- hendrik From jay.krell at cornell.edu Thu Jul 16 22:36:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 20:36:42 +0000 Subject: [M3devel] M3Config Message-ID: So..I was wondering..what were the original authors thinking? And there was that comment about the file containing the data upon install. Which seemed wrong to me. They were probably thinking of the way 3.6 was packaged and distributed -- everyone built the system from source, upon building m3build/m3ship from C and m3 from assembly. That isn't a bad model, but we probably want both. There are at least three times the paths can be computed/recorded: 1) when you build libm3 2) when you install libm3 #1 and #2 may or may not be close in time and have the same result. 3) by parsing cm3.cfg as needed #2 is more efficient than #3 and matches the old code, but #3 is how I left it, probably ok. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 23:01:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 21:01:03 +0000 Subject: [M3devel] comment in Xmacro.m3 questioning correctness? Message-ID: C:\dev2\cm3.2\m3-ui\motif\src\Xmacro.m3(24): (* does this work on big-endian machines?? *) (*-----------------*) PROCEDURE CharVal(value:CHAR):Xt.ArgVal= BEGIN RETURN LOOPHOLE (ORD (value), Xt.ArgVal); (* does this work on big-endian machines?? *) END CharVal; The code is ok? Otherwise I can write it in portable C.. But I suspect it is ok and we can just strike the comment. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 09:40:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 07:40:07 +0000 Subject: [M3devel] suggest removing version numbers from library names Message-ID: versioning dynamic libraries/shared objects We do, like Darwin: libfoo.5.dylib symlink libfoo.5.2.dylib symlink libfoo.dylib actual file others: libfoo.so.5 symlink libfoo.so as are the conventions. (HP-UX I think just .sa instead of .so.) (NT: Just foo.dll.) I understand the point of this. I may be heretical and lazy, but I am not (entirely) ignorant. :) I suggest that maybe compatibility ("binary" *and* behavioral) and managing version numbers is too difficult, not worth it, that instead programs carry their dependencies with them, and that we just have: libfoo.dylib libfoo.so I further suggest, though it is independent, that we move the lib directory contents into bin. That makes "movement" or "relocation" just slightly easier. I further suggest that most people only consider "binary" compatibility, the parameter order and types of functions, the layout of structs, which is already maybe too difficult, and once one realizes that compatibility includes behavior, the problem is even much larger. I acknowledge that if everyone took this approach, the result would not be great. I assert that carrying dependencies with you eliminates much of the point of dynamic linking, but not all -- you still share among the contents of the same bin directory, code presumably all built around the same time and/or against the same interfaces. If all of the above is rejected, I assert at least that we should have the major.minor version number in the above names derive directly from the checked in version file, that they become 5.8 for this release on Darwin. Oh, hm. We actually aren't following the conventions. I should check if this is an accidental regression. On Birch I see a mix, of no version, three part version, two part version, though three part extension seems most common. Sometimes versions occur in inconsistent places. /usr/lib/libdbus-1.so.3@ /usr/lib/libdbus-1.so.3.2.0 /usr/lib/libdrvproxy.so@ /usr/lib/libdrvproxy.so.2@ /usr/lib/libdrvproxy.so.2.1.15 /usr/lib/libdb-4.2.so /usr/lib/libdb-4.3.so /usr/lib/libdb-4.4.so /usr/lib/libc.a /usr/lib/libc.so /usr/lib/libform.a /usr/lib/libform.so@ /usr/lib/libform.so.5@ /usr/lib/libform.so.5.5 /usr/lib/libcurl.so.3@ /usr/lib/libcurl.so.3.0.0 /usr/lib/libXt.a /usr/lib/libXt.so.6@ /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 /usr/lib/libpython2.4.so@ /usr/lib/libpython2.4.so.1.0 /usr/lib/libpython2.4.so.1@ /usr/lib/libfreetype.a /usr/lib/libfreetype.la (Yes, I've heard of libtool.) /usr/lib/libfreetype.so@ /usr/lib/libfreetype.so.6@ /usr/lib/libfreetype.so.6.3.10 % more /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-x86- 64.so.2 ) ) % ls /lib/libc* /lib/libc.so.6@ etc. so I amend the previous to 5.8.1 on Linux also, and check what other systems do. But really, the first suggestion -- no versions. I wouldn't mind dropping the "lib" prefix but I think that breaks the static vs. dynamic probing that occurs on Darwin and maybe others. Though we do our own thing on Windows with Modula-3 where have foo.lib dynamic foo.lib.sa standalone and the Quake code handles the probing. It should be further noted that various systems including Linux, Solaris, and I believe some of the BSDs have yet another versioning mechanism in use, where, roughly speaking, functions get version names appended to them, but that is not visible at the source level, not even with #defines or #pragmas or inlines, though there is some of that too. Therefore, they can and do rev file names much less frequently than one might expect if one only knew about the use of version numbers in file names. I note this as sort of a counterpoint to the assertion that we should follow the conventions, because, arguably, we aren't fully following them, and probably never will. It'd take inventing new mechanisms to shadow the C mechanisms, and it wouldn't be portable. Realize, $ORIGIN is important to this. NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous. Probably drop support for 4.0. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:28:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:28:58 +0000 Subject: [M3devel] cm3ide crash Message-ID: I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:46:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:46:27 +0000 Subject: [M3devel] FW: cm3ide crash Message-ID: [truncated] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3ide crash Date: Fri, 17 Jul 2009 12:28:58 +0000 I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:46:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:46:02 +0000 Subject: [M3devel] gdb on Darwin Message-ID: Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. AMD64 gives and error that BFD is not supported. x86 skips the critical gdb directory because it isn't supported. If we want this to work, we should probably the importing Apple's fork? Like I did for ARM_DARWIN m3cc? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:47:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:47:26 +0000 Subject: [M3devel] cm3ide crash Message-ID: [truncated again] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3ide crash Date: Fri, 17 Jul 2009 12:28:58 +0000 I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:50:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:50:08 +0000 Subject: [M3devel] cm3ide crash Message-ID: [and again..I'll trim the part that wasn't truncated..] ---- For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 15:48:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 09:48:35 -0400 Subject: [M3devel] cm3ide crash In-Reply-To: References: Message-ID: <60F32660-0DF9-480E-959F-712A51ED0278@cs.purdue.edu> Looks like a null pointer. Sent from my iPhone On Jul 17, 2009, at 8:47 AM, Jay K wrote: > > [truncated again] > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: cm3ide crash > Date: Fri, 17 Jul 2009 12:28:58 +0000 > > > > > > > > > I used cm3ide for a few minutes. > I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when > compiling) it is constructed in a roundabout fashion by running the > code. > See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config > file I usually use. > > Clicking on the examples link: > > (gdb) r > Starting program: /cm3/bin/cm3ide > warning: posix_spawn failed, trying execvp, error: 86 > CAUTION: PKG_USE not defined in cm3.cfg, constructed it from > cm3.cfg path as: /cm3/pkg > CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from > package root as: /cm3/doc > NOTICE: Unable to locate 'examples' folder. > Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 > calling start_browser(http://localhost:3800/) > /Applications/Firefox.app/Contents/MacOS/firefox http://localhost: > 3800/ > starting TCP service > Scanning Packages: Jul 17 05:15... > ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? > scan done: Jul 17 06:27 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > [Switching to process 23997 thread 0x2703] > 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ > Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ > text/Text.m3:16 > #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) > at ../src/os/POSIX/PathnamePosix.m3:65 > #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/ > os/POSIX/FSPosix.m3:243 > #3 0x0000000100042713 in Roots__ScanExamples > (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 > #4 0x0000000100042338 in Roots__ExamplesRootPage > (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, > M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 > #5 0x000000010005abc0 in WebServer__ProcessRequest > (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/ > WebServer.m3:325 > #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) > at ../src/server/TCPServer.m3:116 > #7 0x000000010011b52a in ThreadPThread__RunThread > (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ > ThreadPThread.m3:547 > #8 0x000000010011b1b6 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ > ThreadPThread.m3:523 > #9 0x00007fff82a66deb in _pthread_start () > #10 0x00007fff82a66cad in thread_start () > > There are other problems. > It prompted me for my browser. > > On a Mac, it could offer choices like: > > jaypro:cm3ide jay$ find /Applications | grep -i fox$ > /Applications/Firefox.app/Contents/MacOS/firefox > > jaypro:cm3ide jay$ find /Applications | grep -i fari$ > /Applications/Safari.app/Contents/MacOS/Safari > > if they exist. > Of course I should try Opera and whatever else and report their paths. > > I had to close any existing Firefox, else I got an error that only > one Firefox can run at a time. > The error came from Firefox, not cm3ide. > > For the prompt for editor, I grant there may be too many options to > offer From hosking at cs.purdue.edu Fri Jul 17 15:50:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 09:50:36 -0400 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: Let's avoid pandering to Apple's forks. Better to upgrade to FSF sources that (eventually) should catch up. Sent from my iPhone On Jul 17, 2009, at 8:46 AM, Jay K wrote: > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. > AMD64 gives and error that BFD is not supported. > x86 skips the critical gdb directory because it isn't supported. > > If we want this to work, we should probably the importing Apple's > fork? > Like I did for ARM_DARWIN m3cc? > > - Jay > > > From wagner at elegosoft.com Fri Jul 17 18:51:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 18:51:25 +0200 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Well, it would be great if somebody could (a) provide a short update for the release notes regarding LONGINT and (b) put this into two or three paragraphs (perhaps in their own document) that ordinary users may understand and want to know Olaf Quoting Jay K : > > ps: Interix in fact, outside of Modula-3, can use gcc or Visual C++. > > They have a cc wrapper that translates the command line and calls cl.exe. > > Not sure if both linkers are available -- you know, because Interix > seems to have > > substantial support for stuff Visual C++ link.exe does not have -- > runpath, $origin. > > > > > > As well, Cygwin/mingw/Visual C++ all use the same object file format and > > to a significant extent can link each other's output. > > So you can use Visual C++ with Cygwin, gcc without a cygwin dependency. > > They have/had a gcc -mnocygwin switch, though there is tension > > between "biarch" vs. "just separate targets". > > > > > > So, actually, in cm3, these are all the same "target", "NT386", just > different config files. > > This was an experiment and I'm still feeling mixed about the results. > > > > They way it is constructed leaves it generally pretty easy to > construct the combinations > > that aren't named. You don't have to change cm3 at all, nor I think > any m3makefile, > > just the config file. Well, in the m3makefiles, in m3core, there is > deciding on > > using pthreads or NT threads, since you can use NT threads with Posix cygwin. > > > > > > You know, look at how SOLgnu and SOLsun are implemented -- they are > all identical > > except for the config files. Similar situation but in this case they > were broken > > out into separate targets, and all the target-specific code is /identical/. > > > > > > - Jay > > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Thu, 16 Jul 2009 18:41:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release notes comments > > > > Yes. These are subtle but true points. > > > os = cygwin or mingwin or interix or nt > but mingwin is really nt, this is clarified below > ostype = win32 or posix > but this maps directly from os so isn't a multiplicative factor > fork = fast or slow or none > also maps from os/runtime > backend = gcc or integrated > gcc backend BITSIZE(LONGINT)==64 > integrated backend BITSIZE(LONGINT)==32 > > > I386_CYGWIN (NT386GNU) > Posix, slow fork > gcc backend, BITSIZE(LONGINT)==64 > > I386_MINGWIN (NT386MINGNU) > Win32, probably no fork (though in reality there some hybrid > aspects, intended > only for the use of the compiler/linker/etc., intended not to be > injected into stuff you build) > gcc backend, BITSIZE(LONGINT)==64 > > I386_INTERIX > Posix, fast fork > uses gcc backend, BITSIZE(LONGINT)==64 > > I386_NT (NT386) > Win32, no fork > integrated backend, BITSIZE(LONGINT)==32 > > Cygwin hangs in one of the test cases. > Mingw had some major problem last I checked like crashing in all gui apps. > > More combinations than this make sense. > You could use the integrated backend with Cygwin or Interix for example. > Mingwin, you know, is meant to be NT386 with the gcc backend. > Mingwin is not an OS or runtime. > > Three runtimes: Cygwin, Interix, NT > two backends: integrated, gcc > > therefore 6 combinations of which 4 are named above > > Consider that integrated backend could be adapted for I386_LINUX, > I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, > I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... > > - Jay > > > > > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Thu, 16 Jul 2009 10:39:03 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release notes comments > > > > > > Are there any Windows targets using the gcc-based backend? If so > then they will have BITSIZE(LONGINT)=64 too. It is just the > integrated non-optimizing x86 back-end that currently defines > BITSIZE(LONGINT)=32. > > > On 16 Jul 2009, at 02:24, Olaf Wagner wrote: > > Quoting "Rodney M. Bates" : > > > A couple of comments on the release notes for 5.8.2:
  • System > > pthread threading is now the default on all > > platforms. The original (fast) M3 user level thread code is > > still there and can be used if necessary (on most platforms). On > > many systems, this allows M3 applications to scale over all > > available hardware processors.
  • > > > > This sounds like it is the original user level threads that allow > > scaling over multiple processors, which I believe is backwards. I > > suggest swapping the second and third sentences be for clarity. > >
  • New data type LONGINT (64 bit integer) on all target > > platforms except Windows (still in the queue).
  • > > > > As I understand it, LONGINT is in Windows too, it just isn't 64 > > bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:02:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:02:59 +0200 Subject: [M3devel] M3Config In-Reply-To: References: Message-ID: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> Quoting Jay K : > So..I was wondering..what were the original authors thinking? > > And there was that comment about the file containing the data upon install. > > Which seemed wrong to me. > > They were probably thinking of the way 3.6 was packaged and > distributed -- everyone built the system from source, upon building > m3build/m3ship from C and m3 from assembly. > > That isn't a bad model, but we probably want both. > > There are at least three times the paths can be computed/recorded: > > 1) when you build libm3 > 2) when you install libm3 > #1 and #2 may or may not be close in time and have the same result. > 3) by parsing cm3.cfg as needed > > #2 is more efficient than #3 and matches the old code, but #3 is how > I left it, probably ok. I'd prefer that, too. I take it that you've changed the code correspondingly and we should move the RC2 tag? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:07:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:07:10 +0200 Subject: [M3devel] FW: cm3ide crash In-Reply-To: References: Message-ID: <20090717190710.deb46kibk4k8w40w@mail.elegosoft.com> Can anybody fix that crash? It's probably just a missing text or other NIL pointer (missing examples)... Olaf Quoting Jay K : > I used cm3ide for a few minutes. > I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when > compiling) it is constructed in a roundabout fashion by running the > code. > See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config > file I usually use. > > Clicking on the examples link: > > (gdb) r > Starting program: /cm3/bin/cm3ide > warning: posix_spawn failed, trying execvp, error: 86 > CAUTION: PKG_USE not defined in cm3.cfg, constructed it from > cm3.cfg path as: /cm3/pkg > CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from > package root as: /cm3/doc > NOTICE: Unable to locate 'examples' folder. > Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 > calling start_browser(http://localhost:3800/) > /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ > starting TCP service > Scanning Packages: Jul 17 05:15... > ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? > scan done: Jul 17 06:27 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > [Switching to process 23997 thread 0x2703] > 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at > ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at > ../src/text/Text.m3:16 > #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at > ../src/os/POSIX/PathnamePosix.m3:65 > #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at > ../src/os/POSIX/FSPosix.m3:243 > #3 0x0000000100042713 in Roots__ScanExamples > (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 > #4 0x0000000100042338 in Roots__ExamplesRootPage > (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, > M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 > #5 0x000000010005abc0 in WebServer__ProcessRequest > (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at > ../src/misc/WebServer.m3:325 > #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at > ../src/server/TCPServer.m3:116 > #7 0x000000010011b52a in ThreadPThread__RunThread > (M3_CgoaiZ_me=0x100d02270) at > ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x000000010011b1b6 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x100d02270) at > ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x00007fff82a66deb in _pthread_start () > #10 0x00007fff82a66cad in thread_start () -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:14:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:14:06 +0200 Subject: [M3devel] suggest removing version numbers from library names In-Reply-To: References: Message-ID: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> I think ELF dynamic linkers actually understand just one version number (but may be wrong there). If this is correct, we should probably limit our numbers to that, too. The interesting question is, who is going to increase the number of a dynamic library based on an incompatible change? And can that even be done, or are all the numbers fixed in the config files? I wouldn't be against removing unused complexity. As for moving all libs to bin, I'd postpone that after the release and a perhaps controverse discussion. Olaf Quoting Jay K : > > versioning dynamic libraries/shared objects > > > We do, like > > > Darwin: > libfoo.5.dylib symlink > libfoo.5.2.dylib symlink > libfoo.dylib actual file > > > > others: > libfoo.so.5 symlink > libfoo.so > > > > > > as are the conventions. > > > > (HP-UX I think just .sa instead of .so.) > > (NT: Just foo.dll.) > > > > > I understand the point of this. > I may be heretical and lazy, but I am not (entirely) ignorant. :) > > > > > I suggest that maybe compatibility ("binary" *and* behavioral) and > managing version numbers > is too difficult, not worth it, that instead programs carry their > dependencies with > them, and that we just have: > > > > > libfoo.dylib > libfoo.so > > > > > I further suggest, though it is independent, > that we move the lib directory contents into bin. > That makes "movement" or "relocation" just slightly easier. > > > > > > I further suggest that most people only consider "binary" compatibility, > > the parameter order and types of functions, the layout of structs, > > which is already maybe too difficult, and once one realizes that > compatibility > > includes behavior, the problem is even much larger. > > > > > I acknowledge that if everyone took this approach, the result would > not be great. > > > > > I assert that carrying dependencies with you eliminates much of the point > of dynamic linking, but not all -- you still share among the contents of > the same bin directory, code presumably all built around the same time > and/or against the same interfaces. > > > > > > If all of the above is rejected, I assert at least that we should > have the major.minor version number in the above names derive > directly from the checked in version file, that they become 5.8 for this > release on Darwin. > > > > > Oh, hm. We actually aren't following the conventions. > I should check if this is an accidental regression. > > > > > On Birch I see a mix, of no version, three part version, two part version, > though three part extension seems most common. Sometimes versions > occur in inconsistent > places. > > > > > /usr/lib/libdbus-1.so.3@ > /usr/lib/libdbus-1.so.3.2.0 > > > > > /usr/lib/libdrvproxy.so@ > /usr/lib/libdrvproxy.so.2@ > /usr/lib/libdrvproxy.so.2.1.15 > > > /usr/lib/libdb-4.2.so > /usr/lib/libdb-4.3.so > /usr/lib/libdb-4.4.so > > /usr/lib/libc.a /usr/lib/libc.so > > > > > /usr/lib/libform.a > /usr/lib/libform.so@ > /usr/lib/libform.so.5@ > /usr/lib/libform.so.5.5 > > > > > /usr/lib/libcurl.so.3@ > /usr/lib/libcurl.so.3.0.0 > > > > > /usr/lib/libXt.a /usr/lib/libXt.so.6@ > /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 > > > > > /usr/lib/libpython2.4.so@ > > /usr/lib/libpython2.4.so.1.0 > /usr/lib/libpython2.4.so.1@ > > > > > /usr/lib/libfreetype.a > /usr/lib/libfreetype.la (Yes, I've heard of libtool.) > /usr/lib/libfreetype.so@ > /usr/lib/libfreetype.so.6@ > /usr/lib/libfreetype.so.6.3.10 > > > > % more /usr/lib/libc.so > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf64-x86-64) > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > /lib/ld-linux-x86- > 64.so.2 ) ) > > > > % ls /lib/libc* > /lib/libc.so.6@ > > > etc. > > > so I amend the previous to 5.8.1 on Linux also, and check what other > systems do. > > > > > But really, the first suggestion -- no versions. > > > > > I wouldn't mind dropping the "lib" prefix but I think that breaks the > static vs. dynamic probing that occurs on Darwin and maybe others. > Though we do our own thing on Windows with Modula-3 where have > foo.lib dynamic > foo.lib.sa standalone > > > > > and the Quake code handles the probing. > > > > > It should be further noted that various systems including Linux, > Solaris, and I believe > some of the BSDs have yet another versioning mechanism in use, > where, roughly speaking, > functions get version names appended to them, but that is not > visible at the source level, > not even with #defines or #pragmas or inlines, though there is some > of that too. > > > > > Therefore, they can and do rev file names much less frequently than > one might expect > if one only knew about the use of version numbers in file names. > > > > > I note this as sort of a counterpoint to the assertion that we > should follow the conventions, > because, arguably, we aren't fully following them, and probably never will. > It'd take inventing new mechanisms to shadow the C mechanisms, and > it wouldn't be portable. > > > > > > Realize, $ORIGIN is important to this. > > NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous. > > Probably drop support for 4.0. > > > > > > - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Fri Jul 17 19:26:30 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 13:26:30 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Message-ID: <4A607BEF.1E75.00D7.1@scires.com> Olaf: I have read thru the "Release Notes CM3 5.8.2" page and the "CM3 Release Candidate Index" page. Great job putting this together! Here are some comments for your consideration: 1. The section on "Package", particularly the first paragraph, I think is a bit confusing. The CM3IDE documentation includes a lot of information on packages, so perhaps the missing link in this section should reference that documentation. To me, a package is a set of sources that together represent one compilation unit for the purpose of building a library, program, or other assemblage of information (e.g., documentation). Each package resides in a directory (folder), with sources and generated files in subdirectories (sub folders) of the package's folder. In the top-level CM3 source tree, packages are grouped into categories, with each category represented by a subfolder rooted in that top-level, and the packages comprising each category rooted in the category's folder. 2. I presume that we do intend to make NT386 available for this release, even though it says "Not Available Yet". 3. I find the "-bin-min-" and "-bin-core-" terminology a bit confusing. To me, the "core" of something is the "heart" or "minimal" part of it. Would it make more sense to rename "-bin-core-" to "-bin-std-"? Indeed the explanation given for "core" says in one place that it represents a "standard" installation. In another place it is called "package pool". Also, "min" in one place is called the "central installation hierarchy". Suggest we be consistent. To me it makes more sense to have "min" represent the "minimal installation" and "std" the "standard installation" and "all" represents "everything." 4. I don't understand the "-bin-ws-" concept of "precompiled user workspace" and how it would be useful. Please elaborate. 5. All of the instructions seem to apply for UNIX-like environments. We need to augment these to include how to do it on non-Unix environments, such as Windows. For the scripts, like "install.sh", do we intend to provide Windows command/batch files, e.g. "install.cmd" or "install.bat"? 6. When we finally settle on a release name, need to update the names in these instructions, e.g., replace "d5.8.1-RC1" under "Installation Procedure", and "RC1" in other places. 7. "Installation Procedure" step #5, change "shop" to "ship". 8. "In case of problems" step #4, last line, change "volunteers" to "volunteer" and change "his" to "his/her". Hope some of this helps. Thanks for all your work on this!!! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Fri Jul 17 19:26:40 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 17 Jul 2009 10:26:40 -0700 (PDT) Subject: [M3devel] Request web page updates Message-ID: <670632.92136.qm@web56801.mail.re3.yahoo.com> Hi Olaf, Lets try to get the web site into "ship shape", getting ready for visitors coming to check us out, after reading about the latest release. Can your servers handle the Slashdot effect? Anyways, here are a few suggestions. 1 - Downloads: Could you put a link to the tarball for the 5.8.x release canididate (RC2) onto the web server, more specifically on http://opencm3.net/download.html Once, the final version if 5.8.x is released, remove the link to the RCx tarball, in favor of a permanent link to that final release, just like the 5.4 release. 2 - News: (a) It would also be very nice if the "home" or start page brings up "news" items. I always forget to look at the current news page. Actually I just discovered that it is there. (b) You should add a news item promoting the use of the release candidate, to help expose any regressions before the final release. (c) The major changes to the compiler should be listed somewhere, since the last release shown on the download page. Right now the last release indicated is 5.4. There are some snapshots of 5.5, but not final release of 5.5. 3 - About-CM3: The "About CM3" page, should have a section listing all the changes / enhancements to the language that it accepts vice that described in the language reference from Nelson's SPWM3. For example, WIDECHAR, LONGINT are two new primitive types. Also list all the pragmas recognized by the compiler as that is a compiler unique issue. http://opencm3.net/about-cm3.html It should also list all the architectures that are supported by the compiler. These should always reflect those of the latest "release" version of the compiler. 4 - FAQ: Is there a way to get a single page for the FAQ for the FAQ, one that is easy to print? I haven't had the time to look it over yet, so in time, I will be asking "questions", that we may want to add as FAQ items. 5 - ROADMAP: We should have a page on which we record suggestions for changes to the compiler, libraries, and build system. This should capture the long term goals which require thinking and concurrence among the community. Simple things such as bug fixes would not be listed here. These requested changes (and amendments to them), could then be prioritized, and tracked. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Fri Jul 17 19:35:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:35:13 -0400 Subject: [M3devel] M3Config In-Reply-To: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> References: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> Message-ID: On 17 Jul 2009, at 13:02, Olaf Wagner wrote: > Quoting Jay K : > >> So..I was wondering..what were the original authors thinking? This may be lost in the mists of time. Recall that there were originally two implementations of Modula-3: Olivetti's and DEC's. Remnants of both are in CM3. Perhaps this is an artefact of the merge? >> >> And there was that comment about the file containing the data upon >> install From rcoleburn at scires.com Fri Jul 17 19:41:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 13:41:57 -0400 Subject: [M3devel] cm3ide crash In-Reply-To: References: Message-ID: <4A607F8E.1E75.00D7.1@scires.com> Jay: I've not seen the whole of your message yet; I've received multiple truncated copies. Recall that CM3IDE is the open-source version of "Reactor". Reactor was tightly woven into the CM3 4.1 commercial release. During the install process, cm3install actually adjusted the cm3.cfg file to reflect the installation location, location of your preferred browser, preferred editor, etc. I know you don't use cm3install, and you've made changes to the cm3.cfg files, so if some of this stuff isn't going to be there going forward, I need to make adjustments to CM3IDE. When CM3IDE runs, if it doesn't find these variables in the cm3.cfg file, it tries to locate the appropriate stuff, hence the "CAUTION" messages you saw on stdout. In some cases, it asks the same type question that cm3install would have asked about the editor et al, then saves this information in its configuration file located in the user's home folder. Once the info is saved, it won't prompt you for it again. The error you are getting about the examples folder is probably due to you not copying this folder into your CM3 tree. There are README files explaining all this. If you don't have the examples folder, CM3IDE will still function, except you won't be able to build any of the examples. The examples are all pretty neat IMO, and CM3IDE actually builds them in your private workspace, so you can edit the sources and play around with them without affecting anyone else who wants to try out the examples. Each user gets a fresh copy from the examples folder. Not sure about the crash you are reporting, whether it is due to some problem with your cm3.cfg or your installation or just a bug. I don't experience this crash on Windows, but I have not rebuilt CM3IDE against the latest source tree yet. Perhaps a recent change to the source tree has impacted CM3IDE. I'm supposed to go rafting and camping this weekend with my son's Boy Scout troop, so I don't think I'll have much time to work on this problem. If I get back early, I'll try to look at the problem Sunday evening. Regards, Randy Coleburn >>> Jay K 7/17/2009 8:28 AM >>> I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 19:43:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:43:57 -0400 Subject: [M3devel] Lots of errors in latest Tinderbox on Solaris Message-ID: There seems to be something severely broken: Things like: unable to open "/homes/hosking/tmp/cm3/niagara/cm3/pkg/m3quake/ SOLgnu/.M3EXPORTS" for reading file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/ lib /opt/lib unable to open "/scratch/hosking/work/cm3-ws/ niagara-2009-07-17-10-30-05/cm3/m3-tools/cvsup/suplib/ SOLgnu/.M3EXPORTS" for reading ... Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 19:57:20 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:57:20 -0400 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: Message-ID: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> It seems worrisome that m3tohtml is failing. 34147 HTML package report in /var/folders/Q6/ Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report- I386_DARWIN-2009-07-17-06-27-10.html 34148 >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 / Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34149 === 2009-07-17 06:30:30 cm3 package status run done 34150 === 2009-07-17 06:30:30 build HTML package doc in / Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version 34151 34152 34153 *** 34154 NEXT *** runtime error: 34155 *** Segmentation violation - possible attempt to dereference NIL 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/ Text.m3 34157 *** 34158 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes 34160 8316 Abort trap | m3tohtml -dir html $pkgs 34161 >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/ hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34162 === 2009-07-17 06:30:30 m3tohtml run done -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 17 23:34:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 17:34:57 -0400 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> Message-ID: <4A60B629.1E75.00D7.1@scires.com> I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. Regards, Randy Coleburn >>> Tony Hosking 7/17/2009 1:57 PM >>> It seems worrisome that m3tohtml is failing.34147 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34147 ) HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html34148 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34148 ) >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-0634149 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34149 ) === 2009-07-17 06:30:30 cm3 package status run done34150 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34150 ) === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version34151 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34151 ) 34152 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34152 ) 34153 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34153 ) ***34154 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34154 ) NEXT ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#err51 ) *** runtime error:34155 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34155 ) *** Segmentation violation - possible attempt to dereference NIL34156 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34156 ) *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m334157 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34157 ) ***34158 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34158 ) 34159 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34159 ) regression-scripts/defs.sh: line 712: 8315 Broken pipe yes34160 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34160 ) 8316 Abort trap | m3tohtml -dir html $pkgs34161 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34161 ) >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-0634162 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34162 ) === 2009-07-17 06:30:30 m3tohtml run done CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 18 00:56:23 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 17 Jul 2009 18:56:23 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Message-ID: <20090717225623.GA12084@topoi.pooq.com> On Thu, Jul 16, 2009 at 08:24:22AM +0200, Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > > >A couple of comments on the release notes for 5.8.2:
  • System > >pthread threading is now the default on all > > platforms. The original (fast) M3 user level thread code is > > still there and can be used if necessary (on most platforms). On > > many systems, this allows M3 applications to scale over all > > available hardware processors.
  • > > > >This sounds like it is the original user level threads that allow > >scaling over multiple processors, which I believe is backwards. I > >suggest swapping the second and third sentences be for clarity. > >
  • New data type LONGINT (64 bit integer) on all target > > platforms except Windows (still in the queue).
  • > > > >As I understand it, LONGINT is in Windows too, it just isn't 64 > >bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Current information on Modula 3 is still hard to get, Googling 'Modula 3' still give a lot of links to obsolete information. Perhaps I could update the Wikipedia entry to point to http://www.opencm3.net/releng/ as the place to find information on current development? I know it's only there temporarily, but it's always possible to update it when it moves to its permanent place. Uh ... That is the proper place right now, isn't it? If you approve, I'll do it the next time I'm online long enough (which may not be for a few days; I'm travelling). Unless someone beats me to it, of course. (hint, hint) -- hendrik From jay.krell at cornell.edu Sat Jul 18 01:20:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:20:02 +0000 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: <4A60B629.1E75.00D7.1@scires.com> References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> <4A60B629.1E75.00D7.1@scires.com> Message-ID: Ok sorry I think I understand this all much better now and it should work now. Please let's see how the next runs go. - Jay Date: Fri, 17 Jul 2009 17:34:57 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. Regards, Randy Coleburn >>> Tony Hosking 7/17/2009 1:57 PM >>> It seems worrisome that m3tohtml is failing.34147 HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html 34148 >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34149 === 2009-07-17 06:30:30 cm3 package status run done 34150 === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version 34151 34152 34153 *** 34154 NEXT *** runtime error: 34155 *** Segmentation violation - possible attempt to dereference NIL 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m3 34157 *** 34158 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes 34160 8316 Abort trap | m3tohtml -dir html $pkgs 34161 >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34162 === 2009-07-17 06:30:30 m3tohtml run done -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:27:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:27:42 +0000 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: Apple doesn't push up all its changes, I think because they think/know they wouldn't all be accepted. But granted, actually just supporting a target, should be acceptable. Problems may be more like language changes for Mac source compat, though I'd think with flags to turn them off/on, they'd be ok, but that's another point. The lag does seem severe here though. I guess wait for the gdb 7.0 release and then reevaluate? In the meantime, no m3gdb for I386_DARWIN, AMD64_DARWIN. I haven't tried PPC_DARWIN yet. I agree the forking is unfortunate. Even if it is temporary, it seems to go too long. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 17 Jul 2009 09:50:36 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gdb on Darwin > > Let's avoid pandering to Apple's forks. Better to upgrade to FSF > sources that (eventually) should catch up. > > Sent from my iPhone > > On Jul 17, 2009, at 8:46 AM, Jay K wrote: > > > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. > > AMD64 gives and error that BFD is not supported. > > x86 skips the critical gdb directory because it isn't supported. > > > > If we want this to work, we should probably the importing Apple's > > fork? > > Like I did for ARM_DARWIN m3cc? > > > > - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:37:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:37:39 +0000 Subject: [M3devel] suggest removing version numbers from library names In-Reply-To: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> References: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> Message-ID: I think regarding this file name thing, the linker doesn't have to understand anything at all. Granted that it might. You know, just give an "install name", foo.123.3456, just a string, of arbitrary content, and then manage symlinks appropriately. I'm not sure the dynamic linker has any knowledge of their being numbers and ordering. I thought it was just management of symlinks. And then there is some "internal versioning" that goes on. I don't know if that is all in the static linker or some cooperating between the static linker and dynamic linker. The numbers are in the config files yes. But hey, only about two of them now. :) Unix.common and Darwin.common. That has been the case as long as I've been paying close attention. (Mind you, that's shorter than paying passing attention. :) ) (That is, I'd have to go look at 3.x and 4.x to know, I've just seen 5 and 5.2 forever). > The interesting question is, whois going to increase > the number of a dynamic library based onan incompatible change? And, what is an "incompatible change"? I'm not stupid, I know what an "obvious incompatible change" is, but there are many "subtle possibly incompatible changes", such as to suggest nearly any change is incompatible. Thus, why I suggest it is perhaps almost intractable and just give up, rely on $ORIGIN, and don't support much of a "range" of anything. I just watched Theo de Radt (OpenBSD) talk about release engineering. Some interesting relevant points: "release engineering is testing" I thought testing was an ongoing thing. This actually can vary. "X11 is a big mess" (ok, that's not relevant :) ) "OpenBSD aggressively bumps library version numbers" A passing comment that was hard to hear but I believe he said "We don't believe GNU [or what is ELF?] versioning works and don't use it". I /think/ he was reverring to the "internal versioning" but he didn't elaborate. Maybe I just want him to be referring to it so I can write it off without bothering to understand it. :) OpenBSD's basic fix to release engineering and inadequate testing is dogfooding. /Arguably/ we do that too. We at least build the system and run some tests every day. As to "intensive use" of daily builds, that's harder to see. - Jay > Date: Fri, 17 Jul 2009 19:14:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] suggest removing version numbers from library names > > I think ELF dynamic linkers actually understand just one version number > (but may be wrong there). If this is correct, we should probably > limit our numbers to that, too. The interesting question is, who > is going to increase the number of a dynamic library based on > an incompatible change? And can that even be done, or are all the > numbers fixed in the config files? > > I wouldn't be against removing unused complexity. > > As for moving all libs to bin, I'd postpone that after the release > and a perhaps controverse discussion. > > Olaf > > Quoting Jay K : > > > > > versioning dynamic libraries/shared objects > > > > > > We do, like > > > > > > Darwin: > > libfoo.5.dylib symlink > > libfoo.5.2.dylib symlink > > libfoo.dylib actual file > > > > > > > > others: > > libfoo.so.5 symlink > > libfoo.so > > > > > > > > > > > > as are the conventions. > > > > > > > > (HP-UX I think just .sa instead of .so.) > > > > (NT: Just foo.dll.) > > > > > > > > > > I understand the point of this. > > I may be heretical and lazy, but I am not (entirely) ignorant. :) > > > > > > > > > > I suggest that maybe compatibility ("binary" *and* behavioral) and > > managing version numbers > > is too difficult, not worth it, that instead programs carry their > > dependencies with > > them, and that we just have: > > > > > > > > > > libfoo.dylib > > libfoo.so > > > > > > > > > > I further suggest, though it is independent, > > that we move the lib directory contents into bin. > > That makes "movement" or "relocation" just slightly easier. > > > > > > > > > > > > I further suggest that most people only consider "binary" compatibility, > > > > the parameter order and types of functions, the layout of structs, > > > > which is already maybe too difficult, and once one realizes that > > compatibility > > > > includes behavior, the problem is even much larger. > > > > > > > > > > I acknowledge that if everyone took this approach, the result would > > not be great. > > > > > > > > > > I assert that carrying dependencies with you eliminates much of the point > > of dynamic linking, but not all -- you still share among the contents of > > the same bin directory, code presumably all built around the same time > > and/or against the same interfaces. > > > > > > > > > > > > If all of the above is rejected, I assert at least that we should > > have the major.minor version number in the above names derive > > directly from the checked in version file, that they become 5.8 for this > > release on Darwin. > > > > > > > > > > Oh, hm. We actually aren't following the conventions. > > I should check if this is an accidental regression. > > > > > > > > > > On Birch I see a mix, of no version, three part version, two part version, > > though three part extension seems most common. Sometimes versions > > occur in inconsistent > > places. > > > > > > > > > > /usr/lib/libdbus-1.so.3@ > > /usr/lib/libdbus-1.so.3.2.0 > > > > > > > > > > /usr/lib/libdrvproxy.so@ > > /usr/lib/libdrvproxy.so.2@ > > /usr/lib/libdrvproxy.so.2.1.15 > > > > > > /usr/lib/libdb-4.2.so > > /usr/lib/libdb-4.3.so > > /usr/lib/libdb-4.4.so > > > > /usr/lib/libc.a /usr/lib/libc.so > > > > > > > > > > /usr/lib/libform.a > > /usr/lib/libform.so@ > > /usr/lib/libform.so.5@ > > /usr/lib/libform.so.5.5 > > > > > > > > > > /usr/lib/libcurl.so.3@ > > /usr/lib/libcurl.so.3.0.0 > > > > > > > > > > /usr/lib/libXt.a /usr/lib/libXt.so.6@ > > /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 > > > > > > > > > > /usr/lib/libpython2.4.so@ > > > > /usr/lib/libpython2.4.so.1.0 > > /usr/lib/libpython2.4.so.1@ > > > > > > > > > > /usr/lib/libfreetype.a > > /usr/lib/libfreetype.la (Yes, I've heard of libtool.) > > /usr/lib/libfreetype.so@ > > /usr/lib/libfreetype.so.6@ > > /usr/lib/libfreetype.so.6.3.10 > > > > > > > > % more /usr/lib/libc.so > > /* GNU ld script > > Use the shared library, but some functions are only in > > the static library, so try that secondarily. */ > > OUTPUT_FORMAT(elf64-x86-64) > > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > > /lib/ld-linux-x86- > > 64.so.2 ) ) > > > > > > > > % ls /lib/libc* > > /lib/libc.so.6@ > > > > > > etc. > > > > > > so I amend the previous to 5.8.1 on Linux also, and check what other > > systems do. > > > > > > > > > > But really, the first suggestion -- no versions. > > > > > > > > > > I wouldn't mind dropping the "lib" prefix but I think that breaks the > > static vs. dynamic probing that occurs on Darwin and maybe others. > > Though we do our own thing on Windows with Modula-3 where have > > foo.lib dynamic > > foo.lib.sa standalone > > > > > > > > > > and the Quake code handles the probing. > > > > > > > > > > It should be further noted that various systems including Linux, > > Solaris, and I believe > > some of the BSDs have yet another versioning mechanism in use, > > where, roughly speaking, > > functions get version names appended to them, but that is not > > visible at the source level, > > not even with #defines or #pragmas or inlines, though there is some > > of that too. > > > > > > > > > > Therefore, they can and do rev file names much less frequently than > > one might expect > > if one only knew about the use of version numbers in file names. > > > > > > > > > > I note this as sort of a counterpoint to the assertion that we > > should follow the conventions, > > because, arguably, we aren't fully following them, and probably never will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:40:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:40:41 +0000 Subject: [M3devel] cm3ide crash In-Reply-To: <4A607F8E.1E75.00D7.1@scires.com> References: <4A607F8E.1E75.00D7.1@scires.com> Message-ID: I admit I might have increased the problems. I'll try again with my config file fixes. Truncated stuff: There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. And maybe still CodeWarrior, I can maybe get some paths for it if you want. And maybe BBEdit, I can try a trial version. Komodo. In general of course, many. - Jay Date: Fri, 17 Jul 2009 13:41:57 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] cm3ide crash Jay: I've not seen the whole of your message yet; I've received multiple truncated copies. Recall that CM3IDE is the open-source version of "Reactor". Reactor was tightly woven into the CM3 4.1 commercial release. During the install process, cm3install actually adjusted the cm3.cfg file to reflect the installation location, location of your preferred browser, preferred editor, etc. I know you don't use cm3install, and you've made changes to the cm3.cfg files, so if some of this stuff isn't going to be there going forward, I need to make adjustments to CM3IDE. When CM3IDE runs, if it doesn't find these variables in the cm3.cfg file, it tries to locate the appropriate stuff, hence the "CAUTION" messages you saw on stdout. In some cases, it asks the same type question that cm3install would have asked about the editor et al, then saves this information in its configuration file located in the user's home folder. Once the info is saved, it won't prompt you for it again. The error you are getting about the examples folder is probably due to you not copying this folder into your CM3 tree. There are README files explaining all this. If you don't have the examples folder, CM3IDE will still function, except you won't be able to build any of the examples. The examples are all pretty neat IMO, and CM3IDE actually builds them in your private workspace, so you can edit the sources and play around with them without affecting anyone else who wants to try out the examples. Each user gets a fresh copy from the examples folder. Not sure about the crash you are reporting, whether it is due to some problem with your cm3.cfg or your installation or just a bug. I don't experience this crash on Windows, but I have not rebuilt CM3IDE against the latest source tree yet. Perhaps a recent change to the source tree has impacted CM3IDE. I'm supposed to go rafting and camping this weekend with my son's Boy Scout troop, so I don't think I'll have much time to work on this problem. If I get back early, I'll try to look at the problem Sunday evening. Regards, Randy Coleburn >>> Jay K 7/17/2009 8:28 AM >>> I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:43:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:43:38 +0000 Subject: [M3devel] cm3ide crash In-Reply-To: References: <4A607F8E.1E75.00D7.1@scires.com> Message-ID: [That was also truncated, but the direct send to Randy probably won't be..] > From: jay > To: rcoleburn; m3devel > Date: Fri, 17 Jul 2009 23:40:41 +0000 > Subject: Re: [M3devel] cm3ide crash > > I admit I might have increased the problems. I'll try again with my config file fixes. > Truncated stuff: > [deliberate snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 02:47:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 00:47:32 +0000 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> <4A60B629.1E75.00D7.1@scires.com> Message-ID: Oh darn I also forgot about the m3overrides files. Anywhere I added import("m3quake") needs override(ROOT, "m3-sys/m3quake") or such in the m3overrides -- whatever the existing quake users have (e.g. m3-sys/cm3). I can't get to that now. Can anyone else? Else much later today/tonight/tomorrow. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Fri, 17 Jul 2009 23:20:02 +0000 > Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: > > > > > > > > > Ok sorry I think I understand this all much better now and it should work now. Please let's see how the next runs go. > > > > - Jay > > > ________________________________ > > Date: Fri, 17 Jul 2009 17:34:57 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: > > > I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. > > Regards, > > Randy Coleburn > >>>> Tony Hosking 7/17/2009 1:57 PM>>> > > It seems worrisome that m3tohtml is failing. > > 34147 HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html > 34148>>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 > 34149 === 2009-07-17 06:30:30 cm3 package status run done > 34150 === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version > 34151 > 34152 > 34153 *** > 34154 NEXT *** runtime error: > 34155 *** Segmentation violation - possible attempt to dereference NIL > 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m3 > 34157 *** > 34158 > 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes > 34160 8316 Abort trap | m3tohtml -dir html $pkgs > 34161>>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 > 34162 === 2009-07-17 06:30:30 m3tohtml run done > From jay.krell at cornell.edu Sat Jul 18 02:20:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 17 Jul 2009 17:20:07 -0700 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: <03AC38D3-6818-4D1B-9B53-33582010D25B@hotmail.com> Wait a sec actually the problem might be larger here. Apple has its own object and executable format. I think its own static linker. I think a very old fork of gas. We don't care particularly about 'binutils' but it apparently intersects with gdb in bfd. There is investigation to be done but it wouldn't surprise me if this is a large permanent fork. - Jay (phone) On Jul 17, 2009, at 4:27 PM, Jay K wrote: > Apple doesn't push up all its changes, I think because they think/ > know they wouldn't all be accepted. > But granted, actually just supporting a target, should be acceptable. > Problems may be more like language changes for Mac source compat, > though I'd think with flags to turn them off/on, they'd be ok, but > that's another point. > > The lag does seem severe here though. > I guess wait for the gdb 7.0 release and then reevaluate? > In the meantime, no m3gdb for I386_DARWIN, AMD64_DARWIN. > I haven't tried PPC_DARWIN yet. > > I agree the forking is unfortunate. > Even if it is temporary, it seems to go too long. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Fri, 17 Jul 2009 09:50:36 -0400 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] gdb on Darwin > > > > Let's avoid pandering to Apple's forks. Better to upgrade to FSF > > sources that (eventually) should catch up. > > > > Sent from my iPhone > > > > On Jul 17, 2009, at 8:46 AM, Jay K wrote: > > > > > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/ > AMD64. > > > AMD64 gives and error that BFD is not supported. > > > x86 skips the critical gdb directory because it isn't supported. > > > > > > If we want this to work, we should probably the importing Apple's > > > fork? > > > Like I did for ARM_DARWIN m3cc? > > > > > > - Jay > > > > > > > > > From jay.krell at cornell.edu Sat Jul 18 03:55:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 01:55:37 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Message-ID: > Well, it would be great if somebody could > > (a) provide a short update for the release notes regarding LONGINT and > (b) put this into two or three paragraphs (perhaps in their own > document) that ordinary users may understand and want to know > > Olaf There is a new type LONGINT. It is a 64bit signed integer on all platforms except the native NT "NT386" platform. On NT386 is a 32bits, for now, but we would like to fix that. or There is a new type LONGINT. >> Abstractly, it is a signed integer type with at least as many bits as INTEGER. Concretely it is a 64bit signed integer on all platforms except the native NT "NT386" platform. On NT386 is a 32bits, for now, but we would like to fix that. -- end of relnote, begin commentary -- Depending on some philosophy. Personally I adhere to a simpler philosophy where most integer types are of a fixed known size and will never ever change, you might as well encode the size in the name and use just those types -- int8_t, int16_t, in32_t, int64_t or INT8, INT16, INT32, INT64. And then some other types are exactly the same size as a pointer -- ptrdiff_t, size_t, Modula-3 INTEGER -- and will shrink/grow to fit. And there only exists "flat" address spaces. There is the other philosophy that merely states minimum sizes for all the types and an ordering among them, that allows for, say, every integer type to be 64 bits and many other configurations. - Jay From jay.krell at cornell.edu Sat Jul 18 10:25:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 08:25:06 +0000 Subject: [M3devel] hard link commands in quake? Message-ID: Should we keep the hard link commands in quake or not? They've only been there a short time, they were seen to work, and they are no longer used. Perhaps folks will end up wanting them for some reason?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 11:38:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 11:38:21 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <20090717225623.GA12084@topoi.pooq.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <20090717225623.GA12084@topoi.pooq.com> Message-ID: <20090718113821.ojh9fa6lkoko4gkc@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Current information on Modula 3 is still hard to get, Googling 'Modula > 3' still give a lot of links to obsolete information. Perhaps I could > update the Wikipedia entry to point to http://www.opencm3.net/releng/ as > the place to find information on current development? I know it's only > there temporarily, but it's always possible to update it when it moves > to its permanent place. > > Uh ... That is the proper place right now, isn't it? There are currently two domains associated with M3: www.modula3.org (formerly m3.org) www.opencm3.net (cm3 development) These should be used and known. Recently we were able to secure modula3.com, but I'd like to reserve this for other uses. Of course the old elegosoft links still work, too: modula3.elegosoft.com/{cm3,pm3} should be valid. > If you approve, I'll do it the next time I'm online long enough > (which may not be for a few days; I'm travelling). Unless someone beats > me to it, of course. (hint, hint) Just go ahead... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:36:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:36:16 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <4A607BEF.1E75.00D7.1@scires.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> Message-ID: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Quoting Randy Coleburn : > 1. The section on "Package", particularly the first paragraph, I > think is a bit confusing. The CM3IDE documentation includes a lot > of information on packages, so perhaps the missing link in this > section should reference that documentation. To me, a package is a > set of sources that together represent one compilation unit for the > purpose of building a library, program, or other assemblage of > information (e.g., documentation). Each package resides in a > directory (folder), with sources and generated files in > subdirectories (sub folders) of the package's folder. In the > top-level CM3 source tree, packages are grouped into categories, > with each category represented by a subfolder rooted in that > top-level, and the packages comprising each category rooted in the > category's folder. Actually that part was copied from an older document by Neels, I think. What's the exact link you have i nmnd? http://www.opencm3.net/doc/help/cm3/packages.html? > 2. I presume that we do intend to make NT386 available for this > release, even though it says "Not Available Yet". Yes. Nobody has built any though. You or Jay may want to do that once we have fixed RC2. > 3. I find the "-bin-min-" and "-bin-core-" terminology a bit > confusing. To me, the "core" of something is the "heart" or > "minimal" part of it. Would it make more sense to rename > "-bin-core-" to "-bin-std-"? Indeed the explanation given for > "core" says in one place that it represents a "standard" > installation. In another place it is called "package pool". Also, > "min" in one place is called the "central installation hierarchy". > Suggest we be consistent. To me it makes more sense to have "min" > represent the "minimal installation" and "std" the "standard > installation" and "all" represents "everything." I grant it may be confusing, but am somewhat reluctant to change that now. It's legacy from the older package collections (all defined in pkginfo.txt) and used by a lot of scripts, IIRC. We have a `standard' collection there, too, but that has grown to `all' in the meantime. `min' was always the smallest possible installation (just cm3, m3core, libm3). `core' could be thought of as the packages needed to build the system itself (plus some useful libraries :-/). You're right, it's not really accurate, but I'd rather not change it for this release. Anybody's welcome to do it afterwards. Perhaps we could improve the explanation on the web pages? > 4. I don't understand the "-bin-ws-" concept of "precompiled user > workspace" and how it would be useful. Please elaborate. Copied from a mail I sent to Jay some weeks ago: ---- The idea was to reduce the number of packages, as M3 does not really support the separation of source and derived files for binary packages. So why not just enrich the source with just the products needed for shipping? This is sort of the smallest supported _M3_-binary package. Both system-dependent source and binary packages can be based on the same collection of ws packages. Traditionally CM3 offered only sources packages except for the minimal installation archive. There were lots of problems with o people understanding how to compile the source and o actual compilation errors due to miscellaneous causes People wanted something that is easy to install (without using lots of complex scripts). So I extended the standard cm3 builder so it can be used for such an installation. These are exactly the ws archives. M3 source and derived files which are needed for shipping an M3 package, but not more. I found that rather nice. ---- Does that make it clearer? > 5. All of the instructions seem to apply for UNIX-like > environments. We need to augment these to include how to do it on > non-Unix environments, such as Windows. For the scripts, like > "install.sh", do we intend to provide Windows command/batch files, > e.g. "install.cmd" or "install.bat"? Yes, I haven't spent much thought on Windows until now. I hoped that you or Jay will do that. Of course I've also overseen the install.cmd scripts for Windows :-/ Should we use cmd or bat? Could somebody quickly provide the equivalent of this loop, so that I can automate it? ---- #!/bin/sh HERE=`pwd` for p in m3-win/import-libs ... m3-comm/tcp; do cd $p cm3 -ship ${SHIPARGS} cd $HERE done ---- > 6. When we finally settle on a release name, need to update the > names in these instructions, e.g., replace "d5.8.1-RC1" under > "Installation Procedure", and "RC1" in other places. Much of the RCs is generated, but we'll probably have to replace some manually. > 7. "Installation Procedure" step #5, change "shop" to "ship". done > 8. "In case of problems" step #4, last line, change "volunteers" to > "volunteer" and change "his" to "his/her". done > Hope some of this helps. Sure. Updates are online and checked-in. Thanks for the comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:45:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:45:24 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090716173929.GB9087@topoi.pooq.com> References: <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> <20090630175228.GA16767@topoi.pooq.com> <20090716173929.GB9087@topoi.pooq.com> Message-ID: <20090718124524.4p91p1m0e8sw4404@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Jun 30, 2009 at 01:52:28PM -0400, hendrik at topoi.pooq.com wrote: >> On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: >> > >> > If it now just works and the problem cannot be reproduced, we should >> > leave it that way. I wouldn't invest much time on chasing down such >> > a spurious error now. >> >> OK. I'll take a look at installation instructions for some of the other >> packages, such as the one with Trestle. >> >> -- hendrik > > Installed the collection m3gdb from archive > cm3-bin-ws-m3gdb-LINUXLIBC6-d5.8.1-RC1.tgz; it installed flawlessly on > Debian squeeze (32-bit intel). > > Did the same for m3gui, had a glitch. It's at the end of the shell log > below. I've provided the entire log, starting with untarring the > archive, in case you need context. I think that's already fixed and should not occur with the next archive set. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:52:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:52:27 +0200 Subject: [M3devel] Request web page updates In-Reply-To: <670632.92136.qm@web56801.mail.re3.yahoo.com> References: <670632.92136.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090718125227.utf4lmyigwss0s48@mail.elegosoft.com> Hi Peter, thanks for the concrete suggestions. There are no RC2 packages yet, because there have been changes and further problems. Of course we'll have to adapt the web presentation, but I'd like to wait until the packages are there. If you like, you can already make changes to the pages checked-in to cm3/www though. www.opencm3.net/releng is not publicly linked by intention yet. I'm not sure if we can release RC2 this weekend, and I'm really busy during the week. I'll provide a status list from my point of view to better coordinate things. Thanks again, Olaf Quoting Peter Eiserloh : > Hi Olaf, > > Lets try to get the web site into "ship shape", getting ready > for visitors coming to check us out, after reading about the > latest release. Can your servers handle the Slashdot effect? > > Anyways, here are a few suggestions. > > > 1 - Downloads: Could you put a link to the tarball for the > 5.8.x release canididate (RC2) onto the web server, more > specifically on > > http://opencm3.net/download.html > > Once, the final version if 5.8.x is released, remove the link to the > RCx tarball, in favor of a permanent link to that final release, > just like the 5.4 release. > > > 2 - News: (a) It would also be very nice if the "home" or start page > brings up "news" items. I always forget to look at the > current news page. Actually I just discovered that it is > there. > > (b) You should add a news item promoting the use of the release > candidate, to help expose any regressions before the final > release. > > (c) The major changes to the compiler should be listed > somewhere, since the last release shown on the download > page. Right now the last release indicated is 5.4. > There are some snapshots of 5.5, but not final release > of 5.5. > > > 3 - About-CM3: The "About CM3" page, should have a section > listing all the changes / enhancements to the language that > it accepts vice that described in the language reference > from Nelson's SPWM3. > > For example, WIDECHAR, LONGINT are two new primitive types. > > Also list all the pragmas recognized by the compiler as > that is a compiler unique issue. > > http://opencm3.net/about-cm3.html > > It should also list all the architectures that are supported > by the compiler. These should always reflect those of the > latest "release" version of the compiler. > > > 4 - FAQ: Is there a way to get a single page for the FAQ > for the FAQ, one that is easy to print? > > I haven't had the time to look it over yet, so in time, > I will be asking "questions", that we may want to add > as FAQ items. > > > 5 - ROADMAP: We should have a page on which we record > suggestions for changes to the compiler, libraries, and > build system. This should capture the long term goals > which require thinking and concurrence among the community. > Simple things such as bug fixes would not be listed here. > > These requested changes (and amendments to them), could > then be prioritized, and tracked. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 13:42:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 11:42:29 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: > > 4. I don't understand the "-bin-ws-" concept of "precompiled user > > workspace" and how it would be useful. Please elaborate. > > Copied from a mail I sent to Jay some weeks ago: I actually still don't understand that. Archiving up the installed form includes source. What is the value of doing the ship/directory reorganization upon install? However, it is kind of a step toward a distribution that includes assembly for everything and then assemble, c compile, link, and ship on the target. (You might even use autoconf/libtool, though their powers will be severely constrained by the presence of assembly.) And such a distribution is easily cross built for all targets in one fell automated swoop on one host, good, valuable that way. > Yes, I haven't spent much thought on Windows until now. I hoped that > you or Jay will do that. Of course I've also overseen the install.cmd > scripts for Windows :-/ Should we use cmd or bat? Could somebody > quickly provide the equivalent of this loop, so that I can > automate it? There are recent builds on http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip as well as: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PPC_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PPC_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PPC_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PPC_LINUX-d5.8.1.tar.gz etc. sorry.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 13:56:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 13:56:25 +0200 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> Quoting Jay K : >> > 4. I don't understand the "-bin-ws-" concept of "precompiled user >> > workspace" and how it would be useful. Please elaborate. >> >> Copied from a mail I sent to Jay some weeks ago: > > I actually still don't understand that. Strange. > Archiving up the installed form includes source. No, only partial sources (historically the IFs, in CM3 modules, too -- but no makefiles for example). > What is the value of doing the ship/directory reorganization upon install? Easiest way to combine complete _usable_ source and binary products. > However, it is kind of a step toward a distribution that includes assembly > for everything and then assemble, c compile, link, and ship on the target. > (You might even use autoconf/libtool, though their powers will be severely > constrained by the presence of assembly.) > And such a distribution is easily cross built for all targets in one > fell automated > swoop on one host, good, valuable that way. > >> Yes, I haven't spent much thought on Windows until now. I hoped that >> you or Jay will do that. Of course I've also overseen the install.cmd >> scripts for Windows :-/ Should we use cmd or bat? Could somebody >> quickly provide the equivalent of this loop, so that I can >> automate it? > There are recent builds on > http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > > as well as: > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb [...] > > sorry.. That's not what we're talking about. We're talking about installation archives for Windows for RC2 as they are described in the release notes. There are none. I can build them myself, but then it will take another couple of weeks. No hurry needed though, as we haven't fixed RC2 yet. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 14:12:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:12:48 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> Message-ID: "usable source" as in editable and then rebuildable? Ok, that I see. > No, only partial sources (historically the IFs, in CM3 modules, too -- I didn't realize the history but I did notice the option and considered it to shrink the distributions, but the source is useful for debugging. > but no makefiles for example). To serve as examples and to make it buildable? Ok. Then I like it. :) Like, it is gentler than having newbies use cvs, and gets the versions that match their binaries. Change the release notes? Well, er, um, I guess the "ws" form on Windows might be nice too. You can say this: install.cmd: SetLocal set root=%~dp0 set pkgs= set pkgs=%pkgs% m3-sys/cm3 set pkgs=%pkgs% m3-sys/m3quake set pkgs=%pkgs% m3-libs/m3core etc. for %%a in (%pkgs%) do call :F1 %%a || exit /b 1 goto :eof :F1 set b=%1 rem replace forward slashes with backward slashes set b=%b:/=\% cd %root%\%b% || exit /b 1 cm3 -ship || exit /b 1 goto :eof There is an implied label :eof at the end of files. "goto :eof" is how you "return". You can also create pkgs.txt: m3-sys/cm3 m3-sys/m3quake etc. install.cmd SetLocal set root=%~dp0 for /f %%a in (%root%\pkgs.txt) do call :F1 %%a || exit /b 1 goto :eof :F1 set b=%1 rem replace forward slashes with backward slashes set b=%b:/=\% cd %root%\%b% || exit /b 1 cm3 -ship || exit /b 1 goto :eof I guess ideally pkgs.txt is identical files across all platforms, though maybe alter the newlines, and then you write install.sh and install.cmd that are constant and look for pkgs.txt "next to" them? This "advanced" sort of cmd won't work on Win9x but it should work pretty far back on NT like to 4.0 or maybe 3.51. For Win9x compat, and actual even for sanity, you'd might want to consider install.js or install.vbs. .js is a pretty ok language and .cmd is awful after a few lines. I guess I'll do this -- install.cmd + pkgs.txt. - Jay > Date: Sat, 18 Jul 2009 13:56:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Release notes comments > > Quoting Jay K : > > >> > 4. I don't understand the "-bin-ws-" concept of "precompiled user > >> > workspace" and how it would be useful. Please elaborate. > >> > >> Copied from a mail I sent to Jay some weeks ago: > > > > I actually still don't understand that. > Strange. > > > Archiving up the installed form includes source. > No, only partial sources (historically the IFs, in CM3 modules, too -- > but no makefiles for example). > > > What is the value of doing the ship/directory reorganization upon install? > Easiest way to combine complete _usable_ source and binary products. > > > However, it is kind of a step toward a distribution that includes assembly > > for everything and then assemble, c compile, link, and ship on the target. > > (You might even use autoconf/libtool, though their powers will be severely > > constrained by the presence of assembly.) > > And such a distribution is easily cross built for all targets in one > > fell automated > > swoop on one host, good, valuable that way. > > > >> Yes, I haven't spent much thought on Windows until now. I hoped that > >> you or Jay will do that. Of course I've also overseen the install.cmd > >> scripts for Windows :-/ Should we use cmd or bat? Could somebody > >> quickly provide the equivalent of this loop, so that I can > >> automate it? > > > There are recent builds on > > http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. > > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > > > > as well as: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb > [...] > > > > sorry.. > > That's not what we're talking about. We're talking about installation > archives for Windows for RC2 as they are described in the release > notes. There are none. > > I can build them myself, but then it will take another couple of weeks. > No hurry needed though, as we haven't fixed RC2 yet. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:17:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:17:03 +0000 Subject: [M3devel] crossing from 64bit to 32bit? Message-ID: There appears to be a problem cross building from a 64bit host to a 32bit target. For example host=AMD64_DARWIN, target=PPC_DARWIN: == package /dev2/cm3/m3-sys/m3back == +++ /cm3/bin/cm3 -build -override -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=2009-05-16 @M3novm -boot -keep +++ --- building in PPC_DARWIN --- "../src/M3x86.m3", line 1549: set domain too large "../src/M3x86.m3", line 1570: set domain too large *** *** runtime error: *** An array subscript was out of range. *** file "../src/exprs/SetExpr.m3", line 701 *** I guess I should look at it.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 14:18:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 14:18:22 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king Message-ID: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> We really need to use some tools to help us keep (or gain?) control of the release process. Trac has been available for more than a year, but nobody has actively used it. Maybe this is a good time now :-) I've started by sketching a roadmap with RC2, 5.8 and 5.9. See here: https://projects.elego.de/cm3/roadmap Please add all the problems that were just reported via mail to the trac database with `new ticket': https://projects.elego.de/cm3/newticket. I've tried it for the cm3ide crash (ticket 1002); it seems to work fine. Some older bug reports are also still unresolved, but we can check them later. It would also be helpful if all active developers had personalized access and would help updating the tickets and the WiKi. Please send mail to admins(at)elego.de to obtain an account from Michael or Joffrey. Please let's use this; I'm afraid we'll lose control without it. It also has the advantage that the HTTP GUI is accessible from the customer network I'm usually working on (while everything else is blocked). Thanks in advance for your cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 14:17:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:17:28 +0000 Subject: [M3devel] crossing from 64bit to 32bit? Message-ID: (same thing crossing to I386_DARWIN) From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: crossing from 64bit to 32bit? Date: Sat, 18 Jul 2009 12:17:03 +0000 There appears to be a problem cross building from a 64bit host to a 32bit target. For example host=AMD64_DARWIN, target=PPC_DARWIN: == package /dev2/cm3/m3-sys/m3back == +++ /cm3/bin/cm3 -build -override -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=2009-05-16 @M3novm -boot -keep +++ --- building in PPC_DARWIN --- "../src/M3x86.m3", line 1549: set domain too large "../src/M3x86.m3", line 1570: set domain too large *** *** runtime error: *** An array subscript was out of range. *** file "../src/exprs/SetExpr.m3", line 701 *** I guess I should look at it.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:27:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:27:46 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: My opinion on some of these: cm3ide crash (NIL pointer?) #1002 probably fixed but needs retesting m3tohtml crash probably fixed but needs retesting broken m3overrides probably fixed but need to wait for Tinderbox to confirm I can migrate more of them to the one master, but that's not required. And there are some variations that need to be preserved, so it has to be all human reviewed. remove/simplify dynamic library version numbering? Can be left alone. I advocate removing the versions entirely. However the "complexity" here is very hidden anyway. m3gdb doesn't build on Darwin I think we punt on this for this release. Just update the distribution building to skip it. I think the fix is probably to import Apple's fork. I don't like it either, but it's probably the "best" way (short of the unlikely Apple/FSF merge). mentor startup crash on Darwin PPC_DARWIN? All Darwin? ie: What I reported? Yes sounds bad. Maybe the same thing as formsedit. - Jay > Date: Sat, 18 Jul 2009 14:18:22 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: admins at elego.de > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > We really need to use some tools to help us keep (or gain?) > control of the release process. Trac has been available for more > than a year, but nobody has actively used it. Maybe this is a good > time now :-) > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > See here: https://projects.elego.de/cm3/roadmap > > Please add all the problems that were just reported via mail > to the trac database with `new ticket': > https://projects.elego.de/cm3/newticket. > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > fine. Some older bug reports are also still unresolved, but we can > check them later. > > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. > > Please let's use this; I'm afraid we'll lose control without it. > > It also has the advantage that the HTTP GUI is accessible from the > customer network I'm usually working on (while everything else is > blocked). > > Thanks in advance for your cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:58:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:58:29 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: > cm3ide crash still happens -- if /cm3/examples doesn't exist. Doesn't crash if empty /cm3/examples created. To get it to crash, click on the "examples" link. Now I can't debug it, gdb won't debug my AMD64 binary, wierd. > m3tohtml crash I was able to see it crash, and then not crash with my config file changes. Since it is run in the Tinderbox though, that should provide extra confirmation. remove/simplify dynamic library version numbering? > Can be left alone. I meant specifically for this release. For next release I'd like to reconsider. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Sat, 18 Jul 2009 12:27:46 +0000 CC: admins at elego.de Subject: Re: [M3devel] RC2 Release Engineering Status and Trac-king My opinion on some of these: cm3ide crash (NIL pointer?) #1002 probably fixed but needs retesting m3tohtml crash probably fixed but needs retesting broken m3overrides probably fixed but need to wait for Tinderbox to confirm I can migrate more of them to the one master, but that's not required. And there are some variations that need to be preserved, so it has to be all human reviewed. remove/simplify dynamic library version numbering? Can be left alone. I advocate removing the versions entirely. However the "complexity" here is very hidden anyway. m3gdb doesn't build on Darwin I think we punt on this for this release. Just update the distribution building to skip it. I think the fix is probably to import Apple's fork. I don't like it either, but it's probably the "best" way (short of the unlikely Apple/FSF merge). mentor startup crash on Darwin PPC_DARWIN? All Darwin? ie: What I reported? Yes sounds bad. Maybe the same thing as formsedit. - Jay > Date: Sat, 18 Jul 2009 14:18:22 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: admins at elego.de > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > We really need to use some tools to help us keep (or gain?) > control of the release process. Trac has been available for more > than a year, but nobody has actively used it. Maybe this is a good > time now :-) > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > See here: https://projects.elego.de/cm3/roadmap > > Please add all the problems that were just reported via mail > to the trac database with `new ticket': > https://projects.elego.de/cm3/newticket. > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > fine. Some older bug reports are also still unresolved, but we can > check them later. > > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. > > Please let's use this; I'm afraid we'll lose control without it. > > It also has the advantage that the HTTP GUI is accessible from the > customer network I'm usually working on (while everything else is > blocked). > > Thanks in advance for your cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 15:07:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 13:07:22 +0000 Subject: [M3devel] I386_DARWIN lastok TInderbox red but? Message-ID: The I386_DARWIN lastok build Tinderbox shows as red, but the log looks ok. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 18 16:37:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Jul 2009 10:37:31 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: On 18 Jul 2009, at 08:58, Jay K wrote: > > cm3ide crash > > still happens -- if /cm3/examples doesn't exist. Sounds like instructions need to be explicit to install/copy the examples directory. I've not yet tried cm3ide. > Doesn't crash if empty /cm3/examples created. > To get it to crash, click on the "examples" link. > Now I can't debug it, gdb won't debug my AMD64 binary, wierd. > > > m3tohtml crash > > I was able to see it crash, and then not crash with my config file > changes. > Since it is run in the Tinderbox though, that should provide extra > confirmation. > > remove/simplify dynamic library version numbering? > > > Can be left alone. > > I meant specifically for this release. > For next release I'd like to reconsider. > > > - Jay > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 18 Jul 2009 12:27:46 +0000 > CC: admins at elego.de > Subject: Re: [M3devel] RC2 Release Engineering Status and Trac-king > > My opinion on some of these: > > cm3ide crash (NIL pointer?) #1002 > > probably fixed but needs retesting > > m3tohtml crash > > probably fixed but needs retesting > > broken m3overrides > > probably fixed but need to wait for Tinderbox to confirm > I can migrate more of them to the one master, but that's not required. > And there are some variations that need to be preserved, so it has > to be all > human reviewed. > > remove/simplify dynamic library version numbering? > > Can be left alone. > I advocate removing the versions entirely. > However the "complexity" here is very hidden anyway. > > m3gdb doesn't build on Darwin > > I think we punt on this for this release. > Just update the distribution building to skip it. > I think the fix is probably to import Apple's fork. > I don't like it either, but it's probably the "best" way (short of > the unlikely Apple/FSF merge). > > > mentor startup crash on Darwin > > PPC_DARWIN? All Darwin? > ie: What I reported? > Yes sounds bad. > Maybe the same thing as formsedit. > > > - Jay > > > > Date: Sat, 18 Jul 2009 14:18:22 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: admins at elego.de > > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > > > We really need to use some tools to help us keep (or gain?) > > control of the release process. Trac has been available for more > > than a year, but nobody has actively used it. Maybe this is a good > > time now :-) > > > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > > See here: https://projects.elego.de/cm3/roadmap > > > > Please add all the problems that were just reported via mail > > to the trac database with `new ticket': > > https://projects.elego.de/cm3/newticket. > > > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > > fine. Some older bug reports are also still unresolved, but we can > > check them later. > > > > It would also be helpful if all active developers had personalized > > access and would help updating the tickets and the WiKi. Please send > > mail to admins(at)elego.de to obtain an account from Michael or > Joffrey. > > > > Please let's use this; I'm afraid we'll lose control without it. > > > > It also has the advantage that the HTTP GUI is accessible from the > > customer network I'm usually working on (while everything else is > > blocked). > > > > Thanks in advance for your cooperation, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 18 16:36:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Jul 2009 10:36:05 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> On 18 Jul 2009, at 08:27, Jay K wrote: > mentor startup crash on Darwin > > PPC_DARWIN? All Darwin? > ie: What I reported? > Yes sounds bad. > Maybe the same thing as formsedit. > This one is serious. It is a new bug as far as I know, since I had mentor running fine about a year or so ago. > > - Jay > > > > Date: Sat, 18 Jul 2009 14:18:22 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: admins at elego.de > > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > > > We really need to use some tools to help us keep (or gain?) > > control of the release process. Trac has been available for more > > than a year, but nobody has actively used it. Maybe this is a good > > time now :-) > > > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > > See here: https://projects.elego.de/cm3/roadmap > > > > Please add all the problems that were just reported via mail > > to the trac database with `new ticket': > > https://projects.elego.de/cm3/newticket. > > > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > > fine. Some older bug reports are also still unresolved, but we can > > check them later. > > > > It would also be helpful if all active developers had personalized > > access and would help updating the tickets and the WiKi. Please send > > mail to admins(at)elego.de to obtain an account from Michael or > Joffrey. > > > > Please let's use this; I'm afraid we'll lose control without it. > > > > It also has the advantage that the HTTP GUI is accessible from the > > customer network I'm usually working on (while everything else is > > blocked). > > > > Thanks in advance for your cooperation, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 17:50:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 17:50:32 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> Message-ID: <20090718175032.cnrq4lyhcc48scog@mail.elegosoft.com> Quoting Tony Hosking : > On 18 Jul 2009, at 08:27, Jay K wrote: > >> mentor startup crash on Darwin >> >> PPC_DARWIN? All Darwin? >> ie: What I reported? >> Yes sounds bad. >> Maybe the same thing as formsedit. >> > > This one is serious. It is a new bug as far as I know, since I had > mentor running fine about a year or so ago. Thas was just my bad memory. These things happen without tracking tools. I meant formsedit (already corrected in WiKi). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 18:12:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 18:12:26 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <20090718181226.89oeqfagisggw8sw@mail.elegosoft.com> Quoting Olaf Wagner : > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. I just learned how to add new users via command line, so please just let _me_ know if you want an account. The trac installation seems to be an older version with some bugs; an update will be done during the next weeks. o self administration does not work o adding of users via Admin does not work o generated links in mails are missing /cm3/ o probably more... We'll have to live with that for the next days. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 22:01:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 22:01:44 +0200 Subject: [M3devel] current tinderbox failures Message-ID: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> I386_DARWIN failed with regression-scripts/defs.sh: line 480: ./scripts/do-cm3-core.sh: No such file or directory I don't understand that (the script is definitely there in the repo) SOLgnu fails with Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/unix/solaris-2-x/Usignal.i3 *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/unix/solaris-2-x/Usignal.i3 *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? -DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? -DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? failed *** This must be a problem in the m3makefiles in m3core. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mbishop at esoteriq.org Sat Jul 18 22:55:27 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Sat, 18 Jul 2009 15:55:27 -0500 Subject: [M3devel] It's good to be back! Message-ID: <4A6236BF.5060903@esoteriq.org> For some reason, I stopped getting m3devel messages...and when I sent an email asking if something was wrong with the list, my messages never got through...I checked the archive and saw lots of activity, but my messages never showed up...anyway, I just signed up with another email address, and am getting the messages again. Glad to see there is progress with a "real" release :) From jay.krell at cornell.edu Sun Jul 19 01:50:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 23:50:13 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: > cm3ide crash > still happens -- if /cm3/examples doesn't exist. > Sounds like instructions need to be explicit to install/copy the examples directory. I've not yet tried cm3ide. Still, it should do better when the directory isn't there. Other directories probably too. I'm not a big fan of cm3ide, or any IDE these days really, but I'll try to stick to concrete problems, which are bound to be fairly small. cm3ide is quite unusual in being browser based and that really limits it, esp. targeting browsers from long ago with just a bunch of html, using Flash or Silverlight can result in a browser-based app as good as a non-browser-based app. I don't like IDEs because..long winded, not sure anyone cares..I saved my notes in case anyone does.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 08:02:26 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 18 Jul 2009 23:02:26 -0700 Subject: [M3devel] current tinderbox failures In-Reply-To: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> References: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> Message-ID: <7855629E-9E28-4A40-A299-2FF570FFFC1B@hotmail.com> My ppc Linux run hit the same file not found error. Sparc Linux failed because I gave it a bad cm3.cfg. Still that is great progress for running tinderbox.. - Jay (phone) On Jul 18, 2009, at 1:01 PM, Olaf Wagner wrote: > I386_DARWIN failed with > > regression-scripts/defs.sh: line 480: ./scripts/do-cm3-core.sh: No > such file or directory > > I don't understand that (the script is definitely there in the repo) > > SOLgnu fails with > > Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/ > unix/solaris-2-x/Usignal.i3 > *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/ > Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/ > unix/solaris-2-x/Usignal.i3 > *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/ > niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? - > DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? $RARGS > && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/ > niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? - > DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? failed > *** > > This must be a problem in the m3makefiles in m3core. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Sun Jul 19 17:44:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 15:44:40 +0000 Subject: [M3devel] "kext" In-Reply-To: <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> Message-ID: > I didn't think of that, but I don't think it matters; there is no > program named kext on Darwin, is there? kextd kextfind kextload kextstat but no kext. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Sun Jul 19 20:49:32 2009 From: rcolebur at scires.com (Randy Coleburn) Date: 19 Jul 2009 14:49:32 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: <4A63326E.1E75.00D7.1@scires.com> >>> Olaf Wagner 7/18/2009 6:36 AM >>> >Yes, I haven't spent much thought on Windows until now. I hoped that >you or Jay will do that. Of course I've also overseen the install.cmd >scripts for Windows :-/ Should we use cmd or bat? Could somebody >quickly provide the equivalent of this loop, so that I can >automate it? > ---- >#!/bin/sh >HERE=`pwd` >for p in m3-win/import-libs ... m3-comm/tcp; do >cd $p >cm3 -ship ${SHIPARGS} >cd $HERE >done > ---- Olaf: Your script can be expressed in Windows .CMD format as follows: REM ---BEGIN--- @echo off for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p goto End :ShipIt echo ...shipping %1... pushd %1 cm3 -ship %SHIPARGS% popd echo. goto :EOF :End echo done @echo on REM ---END--- Of course, the REM lines at the beginning/end are optional, I just put them there to show start/end of the script. Also, you would want to replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of folders to be processed. You can separate them by blank spaces or semi-colons, but if you have a path with an embedded space, you will need to put double quotes around the path. FYI: If your list of paths is in a text file, there is another form of the FOR command that would work to process the list from that file. I don't mind writing .CMD files, so if you and Jay want some help in this area, I am willing to volunteer. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From rcoleburn at scires.com Sun Jul 19 20:58:38 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 14:58:38 -0400 Subject: [M3devel] release testing on Windows XP Message-ID: <4A633472.1E75.00D7.1@scires.com> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Jul 19 22:55:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 16:55:53 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A633472.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> Message-ID: <4A634FED.1E75.00D7.1@scires.com> For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:31:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:31:50 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A634FED.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:33:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:33:14 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis Message-ID: I'm finally getting some progress here! http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1248027392.25281 sparc linux looks good http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248026305.31492 x86 linux unclear but maybe ok http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248022605.3042 ppc linux merge conflict in my PPC_LINUX config file, will try again The ./scripts/do-cm3-core.sh error: Look at the bottom of: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1248038292.4235#err2 pwd 22 /home/jay/work/cm3-ws/localhost-2009-07-19-21-15-43/cm3 23 ls 24 COPYRIGHT-BSD 25 COPYRIGHT-CMASS 26 COPYRIGHT-COLUMBIA 27 COPYRIGHT-DEC 28 COPYRIGHT-JDP 29 COPYRIGHT-PURDUE 30 COPYRIGHT-XEROX 31 COPYRIGHTS 32 CVS 33 README 34 caltech-parser 35 compat.quake 36 doc 37 m3overrides 38 ls ./scripts 39 NEXT ls: cannot access ./scripts: No such file or directory 40 === build core system with current compiler 41 NEXT regression-scripts/defs.sh: line 489: ./scripts/do-cm3-core.sh: No such file or directory Notice the majority of the source is missing, not just scripts. Maybe timing out during the cvs checkout? Maybe we should put in a few cvs -z3 upds at the end of it? Maybe ensure that cvs's exit code is checked? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:33:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:33:48 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A634FED.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: [truncated yet again..] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] release testing on Windows XP Date: Sun, 19 Jul 2009 21:31:50 +0000 Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay [deliberately truncated here] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Sun Jul 19 23:43:02 2009 From: rcolebur at scires.com (Randy Coleburn) Date: 19 Jul 2009 17:43:02 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: <4A635B25.1E75.00D7.1@scires.com> do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Sun Jul 19 23:52:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:52:25 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A635B25.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> Message-ID: The "all" versions of all the scripts fail to compile (all as in Python, .sh, .cmd). Try "std". All the scripts are also a bit identically loose in how they find "projects". They look for something/src/m3makefile where something contains what they are after. It is a bit fragile. Except for your .cmd files which are more precise. There is also a bug in all the scripts that adding new packages to the source tree fails. The PKGS files needs a version number in its name and if PKGS-correctionversion doesn't exist the scripts should delete PKGS* and regenerate. We only recently got a centralized version file though and I didn't want to implement this until that was in. - Jay Date: Sun, 19 Jul 2009 17:43:02 -0400 From: rcolebur at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] release testing on Windows XP do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 00:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 22:48:24 +0000 Subject: [M3devel] Tinderbox missing do-cm3-core.sh Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039304.30290#err2 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039913.18931#err2 to more instances of missing do-cm3-core.sh. You can see in these cases the cvs checkout got much further, but still missed all of scripts. Scripts just happens to be alphabetically late so has a higher chance of not making it. Suggestions? Surely this is just as much likely flaky network on my end as anywhere else. Put a file "last" in the repository and if it is missing after checkout, abort and start over? Send the repository down as one large .tar.gz, and again, if failed to recieve, abort and start over? Could keeping a checkout and just updating it from run to run be made reliable/trusted enough? That would greatly mitigate network problems, make abort + retry less expensive. Or not much competition to the cleanliness of a whole new checkout for each build? Just run it all in an hourly loop and accept the lossage? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 00:50:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 22:50:23 +0000 Subject: [M3devel] FW: Tinderbox missing do-cm3-core.sh Message-ID: [truncated again!] From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: Tinderbox missing do-cm3-core.sh Date: Sun, 19 Jul 2009 22:48:24 +0000 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039304.30290#err2 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039913.18931#err2 to more instances of missing do-cm3-core.sh. You can see in these cases the cvs checkout got much further, but still missed all of scripts. Scripts just happens to be alphabetically late so has a higher chance of not making it. Suggestions? Surely this is just as much likely flaky network on my end as anywhere else. Put a file "last" in the repository and if it is missing after checkout, abort and start over? Send the repository down as one large .tar.gz, and again, if failed to recieve, abort and start over? Could keeping a checkout and just updating it from run to run be made reliable/trusted enough? That would greatly mitigate network problems, make abort + retry less expensive. Or not much competition to the cleanliness of a whole new checkout for each build? Just run it all in an hourly loop and accept the lossage? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Jul 20 04:19:26 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 22:19:26 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> Message-ID: <4A639BC0.1E75.00D7.1@scires.com> Ok, so here is what I've done: 1. deleted PKGS 2. scripts/win/upgrade.cmd 3. scripts/win/do-cm3-std.cmd These work, except that I had to modify pkginfo.txt as follows: 1. Removed all m3-www packages (web & proxy) 2. Removed all cvsup packages If I left these in there, I got failures. BTW, I've rebuilt cm3ide and it is running on Windows XP with no crashes so far. Now, if (?) the pkginfo.txt file is what is driving the process, it appears that each line in the file has a package and one or more tags, e.g. min std core. I assume the order of packages in pkginfo.txt is the correct build order. If these statements are true (and I'm asking you to verify), I will try to write a simpler CMD script that deals with the building process using pkginfo.txt as the "input control file". Regards, Randy Coleburn >>> Jay K 7/19/2009 5:52 PM >>> The "all" versions of all the scripts fail to compile (all as in Python, .sh, .cmd). Try "std". All the scripts are also a bit identically loose in how they find "projects". They look for something/src/m3makefile where something contains what they are after. It is a bit fragile. Except for your .cmd files which are more precise. There is also a bug in all the scripts that adding new packages to the source tree fails. The PKGS files needs a version number in its name and if PKGS-correctionversion doesn't exist the scripts should delete PKGS* and regenerate. We only recently got a centralized version file though and I didn't want to implement this until that was in. - Jay Date: Sun, 19 Jul 2009 17:43:02 -0400 From: rcolebur at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] release testing on Windows XP do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 04:52:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 19 Jul 2009 19:52:07 -0700 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A639BC0.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> Message-ID: <5115ADEF-1DA5-473A-9B15-DD2753CA25D0@hotmail.com> Correct, pkginfo.txt defines the groups and the order. Search for pkginfo. I thought it already drives the .cmd code. Pylib.py has it's own copy but easy to fix. I don't remember but I might have left provision for filtering packages. Originally I wanted the filter conditions expressed somehow in pkginfo.txt but I never did that. - Jay (phone) On Jul 19, 2009, at 7:19 PM, "Randy Coleburn" wrote: > Ok, so here is what I've done: > 1. deleted PKGS > 2. scripts/win/upgrade.cmd > 3. scripts/win/do-cm3-std.cmd > > These work, except that I had to modify pkginfo.txt as follows: > 1. Removed all m3-www packages (web & proxy) > 2. Removed all cvsup packages > > If I left these in there, I got failures. > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > crashes so far. > > Now, if (?) the pkginfo.txt file is what is driving the process, it > appears that each line in the file has a package and one or more > tags, e.g. min std core. I assume the order of packages in > pkginfo.txt is the correct build order. If these statements are > true (and I'm asking you to verify), I will try to write a simpler > CMD script that deals with the building process using pkginfo.txt as > the "input control file". > > Regards, > Randy Coleburn > > >>> Jay K 7/19/2009 5:52 PM >>> > The "all" versions of all the scripts fail to compile (all as in > Python, .sh, .cmd). > Try "std". > > All the scripts are also a bit identically loose in how they find > "projects". > They look for something/src/m3makefile where something contains > what they are after. > It is a bit fragile. > Except for your .cmd files which are more precise. > > There is also a bug in all the scripts that adding new packages to > the source tree fails. > The PKGS files needs a version number in its name and if PKGS- > correctionversion doesn't > exist the scripts should delete PKGS* and regenerate. > We only recently got a centralized version file though and I didn't > want to implement > this until that was in. > > - Jay > > > Date: Sun, 19 Jul 2009 17:43:02 -0400 > From: rcolebur at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] release testing on Windows XP > > do-cm3-all.py: This crazy python animal is now trying to compile my > examples folder! > It fails, of course, and doesn't go any farther. > Regards, > Randy Coleburn > > >>> Jay K 7/19/2009 5:31 PM >>> > Try deleting the PKGS file of course. Management of that file is > poor, across all the scripts. > Almost any version of Python will do and I highly recommend it. .cmd > is a terrible programming language and Python is an excellent one. > Python is also very portable. I use all the same automation across a > variety of platforms. > (I still haven't gotten it to work on OpenBSD/sgimips and I do > sometimes test Olaf's .sh code.) > JScript isn't so bad, and it is "built in" on essentially all > Windows installs (as long as there is IE), but it isn't portable at > all for command line use to Python wins again. I understand the > desire to not install anything at all, but this one install provides > tremendous value. Sometimes a dependency is worth it. > > - Jay > > Date: Sun, 19 Jul 2009 16:55:53 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com; rcoleburn at scires.com > Subject: Re: [M3devel] release testing on Windows XP > > For #3 below, I went to scripts/win and ran upgrade.cmd. No > problems there. > > Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www > \web package is missing. > > I suspect these scripts may not be up to date. > > Alas, I'm going to try to download python 2.6 for Windows since that > is what Jay seems to be using these days. Then I'll try running his > python scripts and see how it fares. > > But, I again think we need to not depend on python scripts for cm3 > on Windows. I am willing to work on the .CMD scripts. > > --Randy Coleburn > > >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> > Olaf / Jay / et al: > > I am back from my trip and thought I would try to test out what we > have for Windows XP platform. > > My plan is: > > 1. Backup my current cm3 tree and sandbox. > 2. Update my local sandbox copy of all CM3 from the CVS repository. > 3. Use my current cm3 to rebuild everthing in the updated sandbox. > In so doing, I will ship back to my cm3 installation thereby > updating it to be current. > 4. Use my updated cm3 to build and test a number of my programs. > 5. Report results to m3devel > > Regards, > Randy Coleburn From wagner at elegosoft.com Mon Jul 20 12:38:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 12:38:33 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: Message-ID: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Quoting Jay K : > Notice the majority of the source is missing, not just scripts. > > Maybe timing out during the cvs checkout? > Maybe we should put in a few cvs -z3 upds at the end of it? > Maybe ensure that cvs's exit code is checked? Yes, that should be checked (isn't it already?). Please add if it's missing. I think the problem may be that birch is operating under high load (at least has done all the weekend), and my attempts to do complete cm3 build didn't alleviate the situation ;-) There's something weird going on, but unfortunately our system administration people are scarce currently due to holidays... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 20 12:44:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 12:44:46 +0200 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A639BC0.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> Message-ID: <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> Quoting Randy Coleburn : > Ok, so here is what I've done: > 1. deleted PKGS > 2. scripts/win/upgrade.cmd > 3. scripts/win/do-cm3-std.cmd > > These work, except that I had to modify pkginfo.txt as follows: > 1. Removed all m3-www packages (web & proxy) > 2. Removed all cvsup packages CVSup will not build on Windows and should be excluded on that platform, but why do the www packages fail? I thought they should be OK. Is there anything specific missing for them in Windows? > If I left these in there, I got failures. > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > crashes so far. Fine. Have you tried without the example folder, too? > Now, if (?) the pkginfo.txt file is what is driving the process, it > appears that each line in the file has a package and one or more > tags, e.g. min std core. I assume the order of packages in > pkginfo.txt is the correct build order. If these statements are > true (and I'm asking you to verify), I will try to write a simpler > CMD script that deals with the building process using pkginfo.txt as > the "input control file". Yes. Sounds right. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 12:55:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 10:55:57 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: > I think the problem may be that birch is operating under high load > (at least has done all the weekend), and my attempts to do complete > cm3 build didn't alleviate the situation ;-) > > There's something weird going on, but unfortunately our system > administration people are scarce currently due to holidays... Could be me?, esp. my repeated Tinderbox runs, doing cvs checkout over and over? No more than three concurrently and not in a loop, but stil.. Three: LINUXLIBC6, PPC_LINUX, SPARC32_LINUX. I can try just one at a time. And, I added -z3 to the checkout? Good/bad/other? gzip is supposedly very non-taxing and I think -z3 is like gzip. I've heard cvs is a cpu hog, it's one reason people switch away from it (which I hope we'll do after this release..) I'll check about the cvs exit code. A few times control-c-ed cvs and my birch ssh would show some errors on syslogd about cvs. - Jay From jay.krell at cornell.edu Mon Jul 20 13:07:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 11:07:21 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: Let's put the exclusions in the three or so m3makefiles instead of coming up with sh, python, and cmd. Just like win-libs only builds on Win32. Which reminds me I should put in the X filtering that way.. And m3gdb... And anything else that isn't really up to the user because the problems run fairly deep (in extreme cases, trying to fix such things, user can edit it away). (The Interix problem with X maybe doesn't run very deep, X is mostly there, but m3gdb on Darwin, cvsup probably NT386...) After this release I think we'll go ahead and unjoin the three NT386 platforms, and rename them all... - Jay ---------------------------------------- > Date: Mon, 20 Jul 2009 12:38:33 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] tinderbox status improvements/diagnosis > > Quoting Jay K : > >> Notice the majority of the source is missing, not just scripts. >> >> Maybe timing out during the cvs checkout? >> Maybe we should put in a few cvs -z3 upds at the end of it? >> Maybe ensure that cvs's exit code is checked? > > Yes, that should be checked (isn't it already?). Please add > if it's missing. > > I think the problem may be that birch is operating under high load > (at least has done all the weekend), and my attempts to do complete > cm3 build didn't alleviate the situation ;-) > > There's something weird going on, but unfortunately our system > administration people are scarce currently due to holidays... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 20 13:12:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 11:12:38 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: wrong thread, this was about cvsup.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Mon, 20 Jul 2009 11:07:21 +0000 > Subject: Re: [M3devel] tinderbox status improvements/diagnosis > > > Let's put the exclusions in the three or so m3makefiles instead of coming up with sh, python, and cmd. Just like win-libs only builds on Win32. [snip] From wagner at elegosoft.com Mon Jul 20 13:51:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 13:51:09 +0200 Subject: [M3devel] Current CM3 test failures on AMD64_LINUX and FreeBSD Message-ID: <20090720135109.3etgatcn4w80w4gg@mail.elegosoft.com> Could anybody have a look at the test failures (red) in http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html? There are also several failures in http://www.opencm3.net/m3tests/m3tests-AMD64_LINUX-2009-07-20-06-12-30.html failures: 18 p009 needs to be adapted for 64 bit platforms (integer size). p040 number conversion routines ASCII <-> binary -- probably always a problem. Has anybody a good idea what to do here? p116b default IEEE floating point tests from Xerox PARC p126 REAL arithmetic p137 bit insert and extract -- probably a 32/64 bit issue, too? p172 REAL vs. C's float -- looks strange (wrong sign) p179 alignment of ARRAY OF BITS 32 FOR INTEGER -- package build failed p204 IP address initializers -- this looks more serious (assertion faiure) p206 ARRAY constructors in var decls using named open array types -- p.b.f. p207 subrange declarations -- p.b.f. p209 open array initializers compile failure -- assertion failure p210 open array initializers runtime failure -- NIL dereference? r002 stack overflow in the main thread -- bus error <-> segmentation fault r003 b3tests/b002 - improper size for an open array parameter -- 32/64 again? r004 negative size for an open array -- line number difference only e020 illegal recursive declaration -- p.b.f <-> segmentation fault e026 two types with the same brand -- empty??? e029 use type instead of value as an initializer -- p.b.f.: ** INTERNAL CG ERROR *** stack not empty, depth (1), looks serious For comparison, here are the failures on FreeBSD (14): p040 binary <-> ASCII conversion routines p116b default IEEE floating point tests from Xerox PARC p172 REAL vs. C's float p185 REAL vs. C float -- not on Linux p204 IP address initializers -- code generator failures p206 ARRAY constructors in var decls using named open array types p207 subrange declarations p209 open array initializers compile failure p210 open array initializers runtime failure r001 unhandled exception r004 negative size for an open array e020 illegal recursive declaration e026 two types with the same brand e029 use type instead of value as an initializer While some of these are probably only problems in the test code or method, it seems to me that we should have a closer look at all of them before the release. Explanations, adaptions of test code and cm3 fixes will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 14:38:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 12:38:31 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> Message-ID: I excluded cvsup on Win32. Everything in m3-www builds ok for me. There is a crashing struct tm bug in the tree, I vaguely recall it was in one of these barely working web browsers. They assume struct tm is the BSDish one with extra stuff at the end, which is only true on some platforms. Oh, this stuff: :\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3 :\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3 typical unsafe Modula-3... - Jay > Date: Mon, 20 Jul 2009 12:44:46 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] release testing on Windows XP > > Quoting Randy Coleburn : > > > Ok, so here is what I've done: > > 1. deleted PKGS > > 2. scripts/win/upgrade.cmd > > 3. scripts/win/do-cm3-std.cmd > > > > These work, except that I had to modify pkginfo.txt as follows: > > 1. Removed all m3-www packages (web & proxy) > > 2. Removed all cvsup packages > > CVSup will not build on Windows and should be excluded on that > platform, but why do the www packages fail? I thought they should > be OK. > > Is there anything specific missing for them in Windows? > > > If I left these in there, I got failures. > > > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > > crashes so far. > > Fine. Have you tried without the example folder, too? > > > Now, if (?) the pkginfo.txt file is what is driving the process, it > > appears that each line in the file has a package and one or more > > tags, e.g. min std core. I assume the order of packages in > > pkginfo.txt is the correct build order. If these statements are > > true (and I'm asking you to verify), I will try to write a simpler > > CMD script that deals with the building process using pkginfo.txt as > > the "input control file". > > Yes. Sounds right. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 20 14:51:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 14:51:42 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis Message-ID: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Quoting Jay K : >> I think the problem may be that birch is operating under high load >> (at least has done all the weekend), and my attempts to do complete >> cm3 build didn't alleviate the situation ;-) >> >> There's something weird going on, but unfortunately our system >> administration people are scarce currently due to holidays... > > Could be me?, esp. my repeated Tinderbox runs, doing cvs checkout > over and over? > No more than three concurrently and not in a loop, but stil.. > Three: LINUXLIBC6, PPC_LINUX, SPARC32_LINUX. > I can try just one at a time. That should be normal business; I rather meant things like the three large bzip2 processes running all day for backup purposes and eating all the cpu time... > And, I added -z3 to the checkout? Good/bad/other? > gzip is supposedly very non-taxing and I think -z3 is like gzip. I found that it's often counter productive to use compression; however, most times small levels are more pratical, so I'd suggest you try -z1. > I've heard cvs is a cpu hog, it's one reason people switch away from > it (which I hope we'll do after this release..) Not that I know... it usually sleeps while waiting for file i/o. > I'll check about the cvs exit code. > > A few times control-c-ed cvs and my birch ssh would show some errors > on syslogd about cvs. Have seen those too yesterday... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 21:04:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 19:04:41 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: How do I get tinderbox to run the tests? It looks like maybe BUILD_REL=lastok does not but letting BUILD_REL default does. I'll fake up a 5.4 install with current files... Let it be known that "lastrel" builds might actually be "lastok" builds. If you can tell which ones are mine.. > I found that it's often counter productive to use compression; > ...so I'd suggest you try -z1. I'll change it later. You might have an unusual viewpoint though -- it is fast to checkout from birch to birch. -z3 is what I recall was recommended. > > I've heard cvs is a cpu hog, it's one reason people switch away from > > it (which I hope we'll do after this release..) I'll have to search, initial searches failed. > Not that I know... it usually sleeps while waiting for file i/o. True. > > I'll check about the cvs exit code. Fix attempted. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 21:56:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 19:56:00 +0000 Subject: [M3devel] tinderbox confusing bin and root? Message-ID: On three machines now I've seen work/cm3-inst/something/bin/bin, bin/pkg, bin/man. It seems that Tinderbox might be messing up the "update"? Maybe I setup these all up wrong myself but I don't think so. I'll see if they come back. I'm just now getting Tinderbox working almost whereas before I was never able to get far. I've gotten "lastok" builds through. I haven't seen tests run but maybe the current attempts will. Since I was using e.g. a new platform SPARC32_LINUX, I setup all the "installations" just by copying files around. The instructions require a 5.4.0 release to exist. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 20 23:39:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 23:39:58 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: <20090720233958.8y2yyvyqecgo0kk0@mail.elegosoft.com> Quoting Jay K : > How do I get tinderbox to run the tests? > > It looks like maybe BUILD_REL=lastok does not but letting BUILD_REL > default does. > > I'll fake up a 5.4 install with current files... > > Let it be known that "lastrel" builds might actually be "lastok" > builds. If you can tell which ones are mine.. Just edit cm3.build like I did on birch: do_tests() { # Enable tests on birch for non-release builds. # FIXME: Must be removed when we have a new release. #if [ "${BUILD_REL}" == "rel" ] ; then std_tests 2>&1 | tee ~/tmp/cm3-tests.log #fi } Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 20 23:44:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 23:44:26 +0200 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: References: Message-ID: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Quoting Jay K : > On three machines now I've seen work/cm3-inst/something/bin/bin, > bin/pkg, bin/man. > It seems that Tinderbox might be messing up the "update"? Looks to me like a problem in shipping or in the cm3 config files... > Maybe I setup these all up wrong myself but I don't think so. > > I'll see if they come back. > > I'm just now getting Tinderbox working almost whereas before I was > never able to get far. > > I've gotten "lastok" builds through. I haven't seen tests run but > maybe the current attempts will. > > Since I was using e.g. a new platform SPARC32_LINUX, I setup all the > "installations" just by > > copying files around. The instructions require a 5.4.0 release to exist. You can just edit cm3.build as written in the last mail and then build lastok. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 01:49:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 23:49:37 +0000 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> References: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Message-ID: > Looks to me like a problem in shipping or in the cm3 config files... Thanks, you're right, I'm missing: INSTALL_ROOT = (path() & SL & "..") in the first cm3.cfg. > You can just edit cm3.build as written in the last mail and then build > lastok. ok, thanks. I don't like having to edit the file, or read the file, just want to read the documenation. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 02:42:58 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 20 Jul 2009 20:42:58 -0400 Subject: [M3devel] do-cm3.cmd for Windows Message-ID: <4A64D69D.1E75.00D7.1@scires.com> I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP that operates based on the "scripts/PkgInfo.txt" file. I have a question about the format of the "scripts/PkgInfo.txt" file. Most of the lines in this file identify a package by name as the first entry on the line. A few of them also provide a relative path to this package. If the source tree is rooted at "sandbox\cm3", we have subfolders "m3-sys", "m3-games", etc. How do we know in which unique subfolder each package is located? For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" while, "netobj" is in "sandbox\cm3\m3-comm\netobj" Then we have in PkgInfo.txt lines like: "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman\kemacs" "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" I can see the need for the relative path for "paneman/kemacs", but "m3-games/badbricks" seems to break with the established pattern. Is this an error in the current PkgInfo.txt file? Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 03:56:38 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 18:56:38 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <4A64D69D.1E75.00D7.1@scires.com> References: <4A64D69D.1E75.00D7.1@scires.com> Message-ID: <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> do-pkg.cmd already does this doesn't it? It is looking for substring matches against paths or somesuch like the .sh code. Not actually package names. - Jay (phone) On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" wrote: > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > that operates based on the "scripts/PkgInfo.txt" file. > > I have a question about the format of the "scripts/PkgInfo.txt" file. > > Most of the lines in this file identify a package by name as the > first entry on the line. A few of them also provide a relative path > to this package. > > If the source tree is rooted at "sandbox\cm3", we have subfolders > "m3-sys", "m3-games", etc. > > How do we know in which unique subfolder each package is located? > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > Then we have in PkgInfo.txt lines like: > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > \kemacs" > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > I can see the need for the relative path for "paneman/kemacs", but > "m3-games/badbricks" seems to break with the established pattern. > Is this an error in the current PkgInfo.txt file? > > Regards, > Randy Coleburn From rcoleburn at scires.com Tue Jul 21 06:50:22 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 00:50:22 -0400 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> Message-ID: <4A651097.1E75.00D7.1@scires.com> Jay: I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3-*.cmd" scripts actually do. Some of the code is pretty complex and I decided it would take me longer to figure it out than to just write a new script. Anyway, you didn't answer my questions, so I've experimented to come up with something that seems to work for the current cases in PkgInfo.txt. I've uploaded a new file "do-cm3.cmd" that processes the "PkgInfo.txt" file based on my understanding of that file's format. I've tested it locally and it seems to work for me. This one .CMD file is meant to be an alternative to all of the various "do-pkg.cmd" and "do-cm3-*.cmd" files. Here are examples of how it could be called: cd "scripts\win" do-cm3 std buildship do-cm3 game clean buildship do-cm3 game realclean build ship do-cm3 comm depends do-cm3 all buildship There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use this file, simply comment-out this block of code or set CM3_DoneSetup=TRUE at the beginning of the block to prevent it from running. If anyone tries my new script, let me know if you experience any problems and I'll try to fix them. Finally, if I want to adapt my "do-cm3.cmd" script to also handle the work of "upgrade.cmd", I'm going to need someone to explain to me the compilation and shipping order for the upgrade process. Regards, Randy Coleburn >>> 7/20/2009 9:56 PM >>> do-pkg.cmd already does this doesn't it? It is looking for substring matches against paths or somesuch like the .sh code. Not actually package names. - Jay (phone) On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" wrote: > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > that operates based on the "scripts/PkgInfo.txt" file. > > I have a question about the format of the "scripts/PkgInfo.txt" file. > > Most of the lines in this file identify a package by name as the > first entry on the line. A few of them also provide a relative path > to this package. > > If the source tree is rooted at "sandbox\cm3", we have subfolders > "m3-sys", "m3-games", etc. > > How do we know in which unique subfolder each package is located? > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > Then we have in PkgInfo.txt lines like: > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > \kemacs" > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > I can see the need for the relative path for "paneman/kemacs", but > "m3-games/badbricks" seems to break with the established pattern. > Is this an error in the current PkgInfo.txt file? > > Regards, > Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 07:28:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 07:28:14 +0200 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: References: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Message-ID: <20090721072814.5hso9gnezo84kssw@mail.elegosoft.com> Quoting Jay K : >> Looks to me like a problem in shipping or in the cm3 config files... > > Thanks, you're right, I'm missing: > > INSTALL_ROOT = (path() & SL & "..") > > in the first cm3.cfg. > >> You can just edit cm3.build as written in the last mail and then build >> lastok. > > > > ok, thanks. I don't like having to edit the file, or read the file, just want > > to read the documenation. > > Well, you have to edit the files anyway to enable the tinderbox communication. And it's no big deal to comment out three more lines ;-) Of course we could define more variables or options... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 07:08:39 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 22:08:39 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <4A651097.1E75.00D7.1@scires.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> Message-ID: <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py. - Jay (phone) On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" wrote: > Jay: > > I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- > *.cmd" scripts actually do. Some of the code is pretty complex and > I decided it would take me longer to figure it out than to just > write a new script. > > Anyway, you didn't answer my questions, so I've experimented to come > up with something that seems to work for the current cases in > PkgInfo.txt. > > I've uploaded a new file "do-cm3.cmd" that processes the > "PkgInfo.txt" file based on my understanding of that file's format. > I've tested it locally and it seems to work for me. > > This one .CMD file is meant to be an alternative to all of the > various "do-pkg.cmd" and "do-cm3-*.cmd" files. > > Here are examples of how it could be called: > cd "scripts\win" > do-cm3 std buildship > do-cm3 game clean buildship > do-cm3 game realclean build ship > do-cm3 comm depends > do-cm3 all buildship > > There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that > expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use > this file, simply comment-out this block of code or set > CM3_DoneSetup=TRUE at the beginning of the block to prevent it from > running. > > If anyone tries my new script, let me know if you experience any > problems and I'll try to fix them. > > Finally, if I want to adapt my "do-cm3.cmd" script to also handle > the work of "upgrade.cmd", I'm going to need someone to explain to > me the compilation and shipping order for the upgrade process. > > Regards, > Randy Coleburn > > >>> 7/20/2009 9:56 PM >>> > do-pkg.cmd already does this doesn't it? > It is looking for substring matches against paths or somesuch like > the .sh code. > Not actually package names. > > - Jay (phone) > > On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" > wrote: > > > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > > that operates based on the "scripts/PkgInfo.txt" file. > > > > I have a question about the format of the "scripts/PkgInfo.txt" > file. > > > > Most of the lines in this file identify a package by name as the > > first entry on the line. A few of them also provide a relative path > > to this package. > > > > If the source tree is rooted at "sandbox\cm3", we have subfolders > > "m3-sys", "m3-games", etc. > > > > How do we know in which unique subfolder each package is located? > > > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > > > Then we have in PkgInfo.txt lines like: > > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > > \kemacs" > > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > > > I can see the need for the relative path for "paneman/kemacs", but > > "m3-games/badbricks" seems to break with the established pattern. > > Is this an error in the current PkgInfo.txt file? > > > > Regards, > > Randy Coleburn > From jay.krell at cornell.edu Tue Jul 21 08:26:42 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 23:26:42 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> Message-ID: <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then clean and build in order from the bottom. You could say it starts after libm3 or at sysutils, but there is also import-libs. In future if released cm3 can build current m3core and libm3 then just build from the bottom and on up, nothing tricky. Thinking about this now I think we should have just done the trick once and then declared the resulting cm3 as the baseline, instead of this 'institutionalization' of the 'workaround' that seems to confuse everyone, and leaves compat hacks in to deal with older releases. I think we should abandon 5.4 as a base before this release so this can be cleaned up. - Jay (phone) On Jul 20, 2009, at 10:08 PM, jay.krell at cornell.edu wrote: > Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py. > > - Jay (phone) > > On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" > wrote: > >> Jay: >> >> I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- >> *.cmd" scripts actually do. Some of the code is pretty complex and >> I decided it would take me longer to figure it out than to just >> write a new script. >> >> Anyway, you didn't answer my questions, so I've experimented to >> come up with something that seems to work for the current cases in >> PkgInfo.txt. >> >> I've uploaded a new file "do-cm3.cmd" that processes the >> "PkgInfo.txt" file based on my understanding of that file's >> format. I've tested it locally and it seems to work for me. >> >> This one .CMD file is meant to be an alternative to all of the >> various "do-pkg.cmd" and "do-cm3-*.cmd" files. >> >> Here are examples of how it could be called: >> cd "scripts\win" >> do-cm3 std buildship >> do-cm3 game clean buildship >> do-cm3 game realclean build ship >> do-cm3 comm depends >> do-cm3 all buildship >> >> There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that >> expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use >> this file, simply comment-out this block of code or set >> CM3_DoneSetup=TRUE at the beginning of the block to prevent it from >> running. >> >> If anyone tries my new script, let me know if you experience any >> problems and I'll try to fix them. >> >> Finally, if I want to adapt my "do-cm3.cmd" script to also handle >> the work of "upgrade.cmd", I'm going to need someone to explain to >> me the compilation and shipping order for the upgrade process. >> >> Regards, >> Randy Coleburn >> >> >>> 7/20/2009 9:56 PM >>> >> do-pkg.cmd already does this doesn't it? >> It is looking for substring matches against paths or somesuch like >> the .sh code. >> Not actually package names. >> >> - Jay (phone) >> >> On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" >> wrote: >> >> > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/ >> XP >> > that operates based on the "scripts/PkgInfo.txt" file. >> > >> > I have a question about the format of the "scripts/PkgInfo.txt" >> file. >> > >> > Most of the lines in this file identify a package by name as the >> > first entry on the line. A few of them also provide a relative >> path >> > to this package. >> > >> > If the source tree is rooted at "sandbox\cm3", we have subfolders >> > "m3-sys", "m3-games", etc. >> > >> > How do we know in which unique subfolder each package is located? >> > >> > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" >> > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" >> > >> > Then we have in PkgInfo.txt lines like: >> > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman >> > \kemacs" >> > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" >> > >> > I can see the need for the relative path for "paneman/kemacs", but >> > "m3-games/badbricks" seems to break with the established pattern. >> > Is this an error in the current PkgInfo.txt file? >> > >> > Regards, >> > Randy Coleburn >> > From rcoleburn at scires.com Tue Jul 21 09:26:56 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 03:26:56 -0400 Subject: [M3devel] status report on Windows XP Message-ID: <4A653548.1E75.00D7.1@scires.com> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 09:38:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 03:38:53 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <4A653815.1E75.00D7.1@scires.com> I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 09:58:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 07:58:27 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: > I've even tried it with the "examples" folder missing and it still works fine. and click the examples link? - Jay Date: Tue, 21 Jul 2009 03:26:56 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] status report on Windows XP This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 10:05:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 08:05:54 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: Bear in mind some features: do-pkg (via sysinfo) does a good job of finding compiler/linker You can copy that, but I also intend to move it into the config files if I can. Though not sure e.g. path/lib/include-search is easy there. And I don't want the config files every time to launch a bunch of processes to do the probing. Maybe move the logic to cm3 itself. Maybe. sets the version defines when building cm3, by reading the version file The python, .sh, and preexisting .cmd do that. You can copy the code out though. Is a little more easily extended -- no builtin list of package groups, but not a big deal. Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. Ditto for do-cm3-std.py wrapping do-pkg.py. The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, and then improved things by introducing pkginfo.txt. Some of the generalizations aren't useful. I'm going to remove the purported support for PM3 and M3 from pylib.py for example. My Python code is still missing a nifty feature that Olaf added to the .sh where you can pass extra parameters on to cm3. Yeah we do need to filter out more packages. The package list has grown since I last used the .cmd files and pylib.py has its own list, so I might not be building those packages on any platform. I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. .cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. Again you might want to try writing JScript. It is much more natural. It can be slow but you aren't likely to notice here. And it is very portable to Windows. You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 10:24:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 08:24:44 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: > Yeah we do need to filter out more packages. If you look for "FilterOnePackage" in pkginfo.cmd you can see this support. I'll see about moving it to the m3makefiles instead though. I'm not sure it deals with the slashes in some of the package paths either. Well..err..clearly not, but not hard to fix. Anyway, I'll see about the m3makefiles. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Tue, 21 Jul 2009 08:05:54 +0000 Subject: Re: [M3devel] status report on Windows XP Bear in mind some features: do-pkg (via sysinfo) does a good job of finding compiler/linker You can copy that, but I also intend to move it into the config files if I can. Though not sure e.g. path/lib/include-search is easy there. And I don't want the config files every time to launch a bunch of processes to do the probing. Maybe move the logic to cm3 itself. Maybe. sets the version defines when building cm3, by reading the version file The python, .sh, and preexisting .cmd do that. You can copy the code out though. Is a little more easily extended -- no builtin list of package groups, but not a big deal. Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. Ditto for do-cm3-std.py wrapping do-pkg.py. The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, and then improved things by introducing pkginfo.txt. Some of the generalizations aren't useful. I'm going to remove the purported support for PM3 and M3 from pylib.py for example. My Python code is still missing a nifty feature that Olaf added to the .sh where you can pass extra parameters on to cm3. Yeah we do need to filter out more packages. The package list has grown since I last used the .cmd files and pylib.py has its own list, so I might not be building those packages on any platform. I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. .cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. Again you might want to try writing JScript. It is much more natural. It can be slow but you aren't likely to notice here. And it is very portable to Windows. You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 10:45:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 10:45:25 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> Message-ID: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > clean and build in order from the bottom. You could say it starts after > libm3 or at sysutils, but there is also import-libs. In future if > released cm3 can build current m3core and libm3 then just build from > the bottom and on up, nothing tricky. Thinking about this now I think > we should have just done the trick once and then declared the resulting > cm3 as the baseline, instead of this 'institutionalization' of the > 'workaround' that seems to confuse everyone, and leaves compat hacks in > to deal with older releases. I think we should abandon 5.4 as a base > before this release so this can be cleaned up. Jay, there is a subtle dependency between the platforms that are contained in cm3 and m3core. You cannot compile a newer m3core with a compiler that doesn't support new platforms. At least I am not aware that this dependency has been removed, or has it? Please explain again in case I missed something. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 10:52:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 10:52:45 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> Quoting Randy Coleburn : > This report is for Windows XP Professional, Service Pack 3, using > Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft > .NET Framework Version 3.5 SP1. > > I've updated my local sandbox to be current with the CM3 CVS > repository at elego. I've performed a "upgrade.cmd" to upgrade my > cm3 compiler to the latest version. > > I kept running into problems with "scripts\win\do-cm3-std.CMD" > stopping short with an error message. > > So, I built my own "do-cm3.CMD" and used it to rebuild everything. > > Here are the packages that fail to build (I think most of these are > not supported currently on Windows): > m3-sys\m3cc > m3-libs\tcl > caltech-parser\term > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib\test We should exclude these packages from builds on Windows for the time being. I'm not sure why the caltech-parser is Unix-dependent, but we can fix that later. > m3-tools\pp Pretty printing shouldn't be Unix-dependent, too, at least I'd think so, but it's also no problem for the release. Nonetheless, coould you write two tickets in trac about failing compilation for the caltech-parser and pp on NT386? Just to make sure we won't forget about it... > I've also built tested CM3IDE and it seems to work fine on Windows. > I've even tried it with the "examples" folder missing and it still > works fine. So it's not reproducible? Or has anything been changed? > I'll try to check out how well some of the other packages run as > time permits. Fine. Thanks for the tests and the report, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 11:02:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 09:02:00 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: I fixed that bug at least in libm3. The dependency was easily removed and very painful when present. see: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 Is there more of it? I haven't see the error in a while. Coincidence? I can test it out.. - Jay > Date: Tue, 21 Jul 2009 10:45:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting jay.krell at cornell.edu: > > > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > > clean and build in order from the bottom. You could say it starts after > > libm3 or at sysutils, but there is also import-libs. In future if > > released cm3 can build current m3core and libm3 then just build from > > the bottom and on up, nothing tricky. Thinking about this now I think > > we should have just done the trick once and then declared the resulting > > cm3 as the baseline, instead of this 'institutionalization' of the > > 'workaround' that seems to confuse everyone, and leaves compat hacks in > > to deal with older releases. I think we should abandon 5.4 as a base > > before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 11:09:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 09:09:11 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: also: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/OSConfigPosix.m3.diff?r1=1.21;r2=1.22 a bunch of dead strings also removed.. There are references to the Compiler type in m3core. C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTDebug.m3(9): EOL = ARRAY Compiler.OS OF TEXT { "\n", "\r\n" }[ Compiler.ThisOS ]; C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RuntimeError.m3(16): self := LOOPHOLE (Compiler.ThisException(), RT0.ActivationPtr).exception; I don't think these are problems, but agreed it is a little fragile. The problem is presumably only present if Compiler.Platform or Compiler.ThisPlatform is referenced. The first use breaks of OS = {Win32, Posix} grows, but that is also trivially fixed. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Tue, 21 Jul 2009 09:02:00 +0000 Subject: Re: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows I fixed that bug at least in libm3. The dependency was easily removed and very painful when present. see: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 Is there more of it? I haven't see the error in a while. Coincidence? I can test it out.. - Jay > Date: Tue, 21 Jul 2009 10:45:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting jay.krell at cornell.edu: > > > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > > clean and build in order from the bottom. You could say it starts after > > libm3 or at sysutils, but there is also import-libs. In future if > > released cm3 can build current m3core and libm3 then just build from > > the bottom and on up, nothing tricky. Thinking about this now I think > > we should have just done the trick once and then declared the resulting > > cm3 as the baseline, instead of this 'institutionalization' of the > > 'workaround' that seems to confuse everyone, and leaves compat hacks in > > to deal with older releases. I think we should abandon 5.4 as a base > > before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 13:30:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 13:30:18 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Quoting Jay K : > I fixed that bug at least in libm3. The dependency was easily > removed and very painful when present. > > see: > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 And that was all? > Is there more of it? I don't know offhand. > I haven't see the error in a while. Coincidence? > > I can test it out.. Yes, please retest it, and if compilation works after addition of a new platform without complex boot upgrade, we'll forget about it. It would be great if that's really past! Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 13:43:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:43:18 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Message-ID: There was another file, C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\OSConfigPosix.m3 or such. and this hack was altered: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(505): IF SocketPosix_IsUltrixOrOSF.Value THEN it was already a hack, and it is still a hack, just not with the bad dependency any longer. Yes, I believe it is fixed. I can't reproduce the problem. I added a target to just C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\Compiler.tmpl which I believe is the only relevant thing in m3core and libm3. The other stuff in libm3 used to be relevant. Hey, /if/ I'm wrong, /and/ we can't fix it, we can go back to the old way. I do have more targets for after 5.8 hopefully. Fixing of the names might be via just adding new targets for example: I386_NT, I386_CYGWIN, I386_MINGW or I386_MINGNUWIN, I386_LINUX, I386_FREEBSD, I386_NETBSD, just not sure about SPARC_SOLARIS or SPARC32_SOLARIS and how to differentiate SOLgnu vs. SOLsun... and other "real" targets anyway, ALPHA_LINUX, ALPHA_*BSD.... Anecdotally I can tell you that even when I knew about and understood the problem, I still encountered the error a bunch, and would fix it. I don't recall seeing it in a while. - Jay > Date: Tue, 21 Jul 2009 13:30:18 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting Jay K : > > > I fixed that bug at least in libm3. The dependency was easily > > removed and very painful when present. > > > > see: > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 > > And that was all? > > > Is there more of it? > > I don't know offhand. > > > I haven't see the error in a while. Coincidence? > > > > I can test it out.. > > Yes, please retest it, and if compilation works after addition of > a new platform without complex boot upgrade, we'll forget about it. > > It would be great if that's really past! > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 13:49:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:49:21 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: These should all be ok now except for m3cc. Hopefully you can filter it out somehow. After the 5.8 release I'll split up the NT386 platforms into three platforms and then the m3cc/src/m3makefile can do the filtering naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but disallowing it for I386_NT). tcl has other problems imho, I disabled it for Win32. It is a massive clone of C headers from years ago and could easily be out of date. The right fix anyway is probably to add Tcl to SYSLIBS -- venturing on actually needing the config files to actually vary per user.. pp requires lex/yacc or flex/bison, and would give an error indicating so. Now it just does nothing if they are missing. caltech requires termios/cfmakeraw, I put in a do-nothing version of Win32 and fixed the Posix version to be safer, more portable, and more and less efficient. I don't know why it was disabling the garbage collector so I removed that. Was that termios.i3 actually portable? Are the structs of known size across all Posix systems and the constants constant? A better Win32 implementation probably isn't difficult. It'd be great if anyone could sign up and say they use this caltech parser stuff, including the terminal stuff it is doing (try removing the cfmakeraw call, notice a difference, and test the Win32 version and verify it doesn't work great..?) Actually I ran some of the executables there and got some usage statements and an array index out of bounds or such in some gui code.. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 13:50:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:50:27 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: [truncated..no big deal...] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] status report on Windows XP Date: Tue, 21 Jul 2009 11:49:21 +0000 These should all be ok now except for m3cc. Hopefully you can filter it out somehow. After the 5.8 release I'll split up the NT386 platforms into three platforms and then the m3cc/src/m3makefile can do the filtering naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but disallowing it for I386_NT). tcl has other problems imho, I disabled it for Win32. It is a massive clone of C headers from years ago and could easily be out of date. The right fix anyway is probably to add Tcl to SYSLIBS -- venturing on actually needing the config files to actually vary per user.. pp requires lex/yacc or flex/bison, and would give an error indicating so. Now it just does nothing if they are missing. caltech requires termios/cfmakeraw, I put in a do-nothing version of Win32 and fixed the Posix version to be safer, more portable, and more and less efficient. I don't know why it was disabling the garbage collector so I removed that. Was that termios.i3 actually portable? Are the structs of known size across all Posix systems and the constants constant? A better Win32 implementation probably isn't difficult. It'd be great if anyone could sign up and say they use this caltech parser stuff, including the terminal stuff it is doing (try removing the cfmakeraw call, notice a difference, and test the Win32 version and verify it doesn't work great..?) Actually I ran some of the executables there and got some usage statements and an array index out of bounds or such in some gui code.. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 14:25:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 12:25:38 +0000 Subject: [M3devel] libodbc may conflict with libodbc.... Message-ID: http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html#tr_m3-sys-cm3 I see that our libodbc.a may conflict with the "real" one. We should probably rename to libm3odbc or such. - Jay From jay.krell at cornell.edu Tue Jul 21 14:37:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 12:37:15 +0000 Subject: [M3devel] config file issue Message-ID: Olaf..sorry, this movement to the config directory seemed very easy at the time..and it is still not quite working. http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/cm3cfg.common", line 170: quake runtime error: undefined variable: ROOT That's probably an old version, where the use isn't guarded with if defined. upgrade.sh: if [ ! -d "${INSTALLROOT}/bin/config" ]; then echo "create new config sub directory ${INSTALLROOT}/bin/config" cp_config_files fi Why the guard with ! -d? How about just always do it? There are other paths...I don't understand..how about just always do it? - Jay From wagner at elegosoft.com Tue Jul 21 16:41:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 16:41:01 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Message-ID: <20090721164101.jjmx0bbk04cc840g@mail.elegosoft.com> Great! Thanks, Olaf Quoting Jay K : > There was another file, > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\OSConfigPosix.m3 or such. > and this hack was altered: > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(505): IF > SocketPosix_IsUltrixOrOSF.Value THEN > > > it was already a hack, and it is still a hack, just not with the bad > dependency any longer. > > > > Yes, I believe it is fixed. > > I can't reproduce the problem. > > I added a target to just > C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\Compiler.tmpl > > which I believe is the only relevant thing in m3core and libm3. > > The other stuff in libm3 used to be relevant. > > > > Hey, /if/ I'm wrong, /and/ we can't fix it, we can go back to the old way. > > I do have more targets for after 5.8 hopefully. > > Fixing of the names might be via just adding new targets for > example: I386_NT, I386_CYGWIN, I386_MINGW or I386_MINGNUWIN, > I386_LINUX, I386_FREEBSD, I386_NETBSD, just not sure about > SPARC_SOLARIS or SPARC32_SOLARIS and how to differentiate SOLgnu vs. > SOLsun... and other "real" targets anyway, ALPHA_LINUX, > ALPHA_*BSD.... > > > > > > Anecdotally I can tell you that even when I knew about and > understood the problem, I still encountered the error a bunch, and > would fix it. I don't recall seeing it in a while. > > > > > > - Jay > >> Date: Tue, 21 Jul 2009 13:30:18 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows >> >> Quoting Jay K : >> >> > I fixed that bug at least in libm3. The dependency was easily >> > removed and very painful when present. >> > >> > see: >> > >> > >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 >> > >> > >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 >> >> And that was all? >> >> > Is there more of it? >> >> I don't know offhand. >> >> > I haven't see the error in a while. Coincidence? >> > >> > I can test it out.. >> >> Yes, please retest it, and if compilation works after addition of >> a new platform without complex boot upgrade, we'll forget about it. >> >> It would be great if that's really past! >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Tue Jul 21 16:42:04 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 10:42:04 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <4A659B7C.1E75.00D7.1@scires.com> yes, I can click the link and cm3ide reports that the examples are not available. --Randy >>> Jay K 7/21/2009 3:58 AM >>> > I've even tried it with the "examples" folder missing and it still works fine. and click the examples link? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Tue Jul 21 16:43:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 16:43:37 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: <20090721164337.j7bbvffiuc08c44k@mail.elegosoft.com> Quoting Jay K : > These should all be ok now except for m3cc. > > Hopefully you can filter it out somehow. > > After the 5.8 release I'll split up the NT386 platforms into three > platforms and then the m3cc/src/m3makefile can do the filtering > naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but > disallowing it for I386_NT). > > tcl has other problems imho, I disabled it for Win32. > > It is a massive clone of C headers from years ago and could easily > be out of date. > > The right fix anyway is probably to add Tcl to SYSLIBS -- venturing > on actually needing the config files to actually vary per user.. Is really anybody using TCL these days? Probably the right thing to do is just remove it ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Jul 21 17:02:28 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:02:28 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: <4A65A009.1E75.00D7.1@scires.com> >>> Jay K 7/21/2009 4:05 AM >>> >Bear in mind some features:> > do-pkg (via sysinfo) does a good job of finding compiler/linker > You can copy that, but I also intend to move it into the config files if I can. > Though not sure e.g. path/lib/include-search is easy there. > And I don't want the config files every time to launch a bunch of processes to do the probing. > Maybe move the logic to cm3 itself. Maybe. My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > sets the version defines when building cm3, by reading the version file > The python, .sh, and preexisting .cmd do that. You can copy the code out though. I thought the version information was built into the compiler? >Is a little more easily extended -- no builtin list of package groups, but not a big deal. >Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >Ditto for do-cm3-std.py wrapping do-pkg.py. This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. >The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >and then improved things by introducing pkginfo.txt. My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. >Some of the generalizations aren't useful. >I'm going to remove the purported support for PM3 and M3 from pylib.py for example. >My Python code is still missing a nifty feature that Olaf added to the .sh where you can >pass extra parameters on to cm3. My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. >Yeah we do need to filter out more packages. >The package list has grown since I last used the .cmd files and pylib.py has its own list, >so I might not be building those packages on any platform. >I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. >.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >Again you might want to try writing JScript. It is much more natural. It can be slow >but you aren't likely to notice here. And it is very portable to Windows. >You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 17:10:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:10:41 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> References: <4A653548.1E75.00D7.1@scires.com> <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> Message-ID: <4A65A1F7.1E75.00D7.1@scires.com> >>> Olaf Wagner 7/21/2009 4:52 AM >>> >Nonetheless, coould you write two tickets in trac about failing >compilation for the caltech-parser and pp on NT386? >Just to make sure we won't forget about it... I can do this, but I will need an account on trac I think in order to do it. Can you set this up for me? --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 17:17:24 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:17:24 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090721095537.18D8ECC806@birch.elegosoft.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> Message-ID: <4A65A389.1E75.00D7.1@scires.com> Granted, I see that Term.m3 is an UNSAFE module, so that by definition means it is not portable. Why though do we want to replace it by nasty C code where non-portable stuff can be easily hidden? This is Modula-3. Why not fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 cents.) --Randy >>> Jay Krell 7/21/2009 11:55 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/07/21 11:55:36 Added files: cm3/caltech-parser/term/src/: TermC.c Log message: initial copy of dangerous non portable Term.m3 to rewrite portably and have it do nothing silently on Win32 which should suffice, or if not, can probably be done better, specifically the MakeRaw function CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 17:18:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:18:49 +0200 Subject: [M3devel] libodbc may conflict with libodbc.... In-Reply-To: References: Message-ID: <20090721171849.52nhb28p8kocwswo@mail.elegosoft.com> Quoting Jay K : > http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html#tr_m3-sys-cm3 > > I see that our libodbc.a may conflict with the "real" one. > We should probably rename to libm3odbc or such. Yes, pelase do. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 17:26:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:26:14 +0200 Subject: [M3devel] config file issue In-Reply-To: References: Message-ID: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> Quoting Jay K : > Olaf..sorry, this movement to the config directory seemed very easy > at the time..and it is still not quite working. > > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 > > > "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/cm3cfg.common", line > 170: quake runtime error: undefined variable: ROOT > > > That's probably an old version, where the use isn't guarded with if defined. > > upgrade.sh: > > if [ ! -d "${INSTALLROOT}/bin/config" ]; then > echo "create new config sub directory ${INSTALLROOT}/bin/config" > cp_config_files > fi > > > Why the guard with ! -d? > How about just always do it? > > There are other paths...I don't understand..how about just always do it? The original idea was to update config files only if the upgrade failed otherwise. That was to preserve any adaptions the end user might have made. To do it right in a real upgrade would require an interactive merge. I've got no problem with forcing the upgrade every time but keeping a backup. Of course, the user will immediately overwrite that with just repeating the command, if we don't version the backup... Please also consider that most users will have the single cm3.cfg which contains everything, while yours just delegates... So I'd vote for providing a backup with a timestamp and then forcing everything to use the new files. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 17:42:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:42:16 +0200 Subject: [M3devel] CM3 Trac access, was: Re: status report on Windows XP Message-ID: <20090721174216.e9wm4hax5sgkkcog@mail.elegosoft.com> Quoting Randy Coleburn : >>>> Olaf Wagner 7/21/2009 4:52 AM >>> >> Nonetheless, coould you write two tickets in trac about failing >> compilation for the caltech-parser and pp on NT386? >> Just to make sure we won't forget about it... > I can do this, but I will need an account on trac I think in order > to do it. Can you set this up for me? Any user should be able to create a new ticket in trac; at least that's how it should be. The link has been on our web pages for over a year; actually nobody has written a ticket, as far as I know ;-) But there were no complaints, too. There are only some old reports migrated grom GNATS. Let me know if it works without password; I'll setup an account for you nonetheless, but can do that only later from home, as the GUI admin function is broken. If anybody would like access, let me know now so I can do it in a batch... Olaf From hosking at cs.purdue.edu Tue Jul 21 18:03:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 12:03:35 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A65A389.1E75.00D7.1@scires.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> Message-ID: <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Hear, hear! Sent from my iPhone On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" wrote: > Granted, I see that Term.m3 is an UNSAFE module, so that by > definition means it is not portable. > Why though do we want to replace it by nasty C code where non- > portable stuff can be easily hidden? This is Modula-3. Why not fix > the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 cents.) > --Randy > > >>> Jay Krell 7/21/2009 11:55 AM >>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/07/21 11:55:36 > > Added files: > cm3/caltech-parser/term/src/: TermC.c > > Log message: > initial copy of dangerous non portable Term.m3 to rewrite portably > and have it do nothing silently on Win32 which should suffice, or if > not, can probably be done better, specifically the MakeRaw function > > From wagner at elegosoft.com Tue Jul 21 18:10:02 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 18:10:02 +0200 Subject: [M3devel] CM3 Continuous Integration with Hudson Message-ID: <20090721181002.7gak37gaaogwg8k8@mail.elegosoft.com> While in preparation for the pending release the target platforms in our tinderbox have grown significantly (though many are still red), I've set up some initial build and test jobs on a new system, which I'd like to replace Tinderbox gradually with during the next weeks or months. Have a look at http://hudson.modula3.com:8080/view/cm3/ Hudson is much more flexible and easier to use than Tinderbox. It can be completely configured and administered via HTTP, including upgrade and restart, which is a big plus at least for me currently (closed network except for HTTP). We can reuse most of the existing scripts, just need to change and adapt some settings. And convert our test results to JUnit XML format, but that's easy, too. Here are some of the advantages I see: o easy setup and configuration o easy online administration o very flexible setup of arbitrary jobs o default integration of CVS and Subversion version control systems, plug-ins for many more o easy integration of HTML and other documents see http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-FreeBSD4/ for an example o continuous integration via CVS polling working out of the box see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/changes and http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/scmPollLog/ o version control integration working out of the box: see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/37/changes#detail2 and http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile?r1=1.51&r2=1.52 o integrated history and trend reports: see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/buildTimeTrend (needs JUnit format for test result evaluation, not done yet) o HTTP access to the complete workspace see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/ws/cm3/ o job report feeds for browser integration see http://hudson.modula3.com:8080/view/cm3/rssFailed o easy configuration backup, migration and transfer, as everything is stored in plain XML files And here are some disadvantages: o more heavyweight, needs more cpu and memory o needs slave installation on every build platform o needs ssh access for slave control, but allows publishing of job results from independent servers (not tested yet) o is written in Java and not Modula-3 :-) I've setup birch as master which also runs jobs for the AMD64_LINUX target platform, and my home computer as a slave server for FreeBSD. If anybody wants access to view the configuration details or try something him/herself, just let me know and I'll set up an account. I also plan to setup actual installation tests before the release. Have fun, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Jul 21 18:19:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 12:19:12 -0400 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: I think Jay already removed the dependency. Yes? Sent from my iPhone On Jul 21, 2009, at 4:45 AM, Olaf Wagner wrote: > Quoting jay.krell at cornell.edu: > >> Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then >> clean and build in order from the bottom. You could say it starts >> after >> libm3 or at sysutils, but there is also import-libs. In future if >> released cm3 can build current m3core and libm3 then just build from >> the bottom and on up, nothing tricky. Thinking about this now I think >> we should have just done the trick once and then declared the >> resulting >> cm3 as the baseline, instead of this 'institutionalization' of the >> 'workaround' that seems to confuse everyone, and leaves compat >> hacks in >> to deal with older releases. I think we should abandon 5.4 as a base >> before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Jul 21 19:53:10 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 21 Jul 2009 10:53:10 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: I might have left it able to be called safe. Honestly I look more for human verifiable safety and correctness and it lacked those before and now does not. If that coincides with machine verifable safety, great. Either way you need C here for correctness and safety. It isn't 'nasty'. Not using C here would be nasty. I think you have it backwards. UNLESS the sizes and constants here are well known but reading docs quickly I didn't see that. Unsafe does not imply not portable. - Jay (phone) On Jul 21, 2009, at 9:03 AM, Tony Hosking wrote: > Hear, hear! > > > Sent from my iPhone > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > wrote: > >> Granted, I see that Term.m3 is an UNSAFE module, so that by >> definition means it is not portable. >> Why though do we want to replace it by nasty C code where non- >> portable stuff can be easily hidden? This is Modula-3. Why not >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >> cents.) >> --Randy >> >> >>> Jay Krell 7/21/2009 11:55 AM >>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/07/21 11:55:36 >> >> Added files: >> cm3/caltech-parser/term/src/: TermC.c >> >> Log message: >> initial copy of dangerous non portable Term.m3 to rewrite portably >> and have it do nothing silently on Win32 which should suffice, or >> if not, can probably be done better, specifically the MakeRaw >> function >> >> > From hosking at cs.purdue.edu Tue Jul 21 20:25:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 14:25:44 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> I assume the argument here is the same as for the POSIX interfaces. Sent from my iPhone On Jul 21, 2009, at 1:53 PM, jay.krell at cornell.edu wrote: > I might have left it able to be called safe. Honestly I look more > for human verifiable safety and correctness and it lacked those > before and now does not. If that coincides with machine verifable > safety, great. Either way you need C here for correctness and > safety. It isn't 'nasty'. Not using C here would be nasty. I think > you have it backwards. UNLESS the sizes and constants here are well > known but reading docs quickly I didn't see that. Unsafe does not > imply not portable. > > - Jay (phone) > > On Jul 21, 2009, at 9:03 AM, Tony Hosking > wrote: > >> Hear, hear! >> >> >> Sent from my iPhone >> >> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >> wrote: >> >>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>> definition means it is not portable. >>> Why though do we want to replace it by nasty C code where non- >>> portable stuff can be easily hidden? This is Modula-3. Why not >>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>> cents.) >>> --Randy >>> >>> >>> Jay Krell 7/21/2009 11:55 AM >>> >>> CVSROOT:/usr/cvs >>> Changes by:jkrell at birch.09/07/21 11:55:36 >>> >>> Added files: >>> cm3/caltech-parser/term/src/: TermC.c >>> >>> Log message: >>> initial copy of dangerous non portable Term.m3 to rewrite portably >>> and have it do nothing silently on Win32 which should suffice, or >>> if not, can probably be done better, specifically the MakeRaw >>> function >>> >>> >> From jay.krell at cornell.edu Tue Jul 21 20:24:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 21 Jul 2009 11:24:05 -0700 Subject: [M3devel] config file issue In-Reply-To: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> References: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> Message-ID: <94281F12-A8E5-4380-BE59-9C7145546679@hotmail.com> Agreed backup and always update. I don't want to consider merging. These are more code than data, but a mix. (code is data...the CPU is an interpreter...) I would like to aim for not needing user edits but that may be impossible to achieve. - Jay (phone) On Jul 21, 2009, at 8:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> Olaf..sorry, this movement to the config directory seemed very >> easy at the time..and it is still not quite working. >> >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 >> >> >> "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/ >> cm3cfg.common", line 170: quake runtime error: undefined variable: >> ROOT >> >> >> That's probably an old version, where the use isn't guarded with if >> defined. >> >> upgrade.sh: >> >> if [ ! -d "${INSTALLROOT}/bin/config" ]; then >> echo "create new config sub directory ${INSTALLROOT}/bin/config" >> cp_config_files >> fi >> >> >> Why the guard with ! -d? >> How about just always do it? >> >> There are other paths...I don't understand..how about just always >> do it? > > The original idea was to update config files only if the upgrade > failed otherwise. That was to preserve any adaptions the end user > might have made. > > To do it right in a real upgrade would require an interactive merge. > I've got no problem with forcing the upgrade every time but keeping > a backup. Of course, the user will immediately overwrite that with > just repeating the command, if we don't version the backup... > > Please also consider that most users will have the single cm3.cfg > which contains everything, while yours just delegates... > > So I'd vote for providing a backup with a timestamp and then forcing > everything to use the new files. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From wagner at elegosoft.com Tue Jul 21 23:19:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 23:19:54 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: <20090721231954.c54oomrbwwcc48cc@mail.elegosoft.com> Quoting Tony Hosking : > I think Jay already removed the dependency. Yes? Seems he did, though I must have missed it :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Jul 21 23:53:31 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 17:53:31 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: <4A66005F.1E75.00D7.1@scires.com> Jay: I guess this topic is just a pet peeve of mine. We tout Modula-3 as a systems programming language and that it has all these great features that make it superior to languages that lack them, yet when we "don't practice what we preach" and use another language it weakens the argument. IMO, using C instead of Modula-3 is kind of like saying that we love baseball, but we have to use soccer to play baseball the right way. It just doesn't add up. I think we should always use Modula-3 in developing and enhancing the CM3 system. I must also disagree with you and state that for a TRUE Modula-3 fan, C is indeed "nasty." All that said, I haven't looked at the code in question here. I simply commented on the idea of replacing M3 code with C code. Regards, Randy >>> 7/21/2009 1:53 PM >>> I might have left it able to be called safe. Honestly I look more for human verifiable safety and correctness and it lacked those before and now does not. If that coincides with machine verifable safety, great. Either way you need C here for correctness and safety. It isn't 'nasty'. Not using C here would be nasty. I think you have it backwards. UNLESS the sizes and constants here are well known but reading docs quickly I didn't see that. Unsafe does not imply not portable. - Jay (phone) On Jul 21, 2009, at 9:03 AM, Tony Hosking wrote: > Hear, hear! > > > Sent from my iPhone > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > wrote: > >> Granted, I see that Term.m3 is an UNSAFE module, so that by >> definition means it is not portable. >> Why though do we want to replace it by nasty C code where non- >> portable stuff can be easily hidden? This is Modula-3. Why not >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >> cents.) >> --Randy >> >> >>> Jay Krell 7/21/2009 11:55 AM >>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/07/21 11:55:36 >> >> Added files: >> cm3/caltech-parser/term/src/: TermC.c >> >> Log message: >> initial copy of dangerous non portable Term.m3 to rewrite portably >> and have it do nothing silently on Win32 which should suffice, or >> if not, can probably be done better, specifically the MakeRaw >> function >> >> > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 23:59:47 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 17:59:47 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> Message-ID: <4A6601D6.1E75.00D7.1@scires.com> Jay, Glad to hear the PkgInfo.txt is viable and being maintained. Right now, I just don't have the time and motivation to learn jscript. I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine. The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks. Regards, Randy >>> 7/21/2009 2:11 PM >>> Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform. The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it. You do have jscript installed and it is pretty easy to read and learn. pkginfo.txt is important and maintained, yes. I need to switch the python to it. Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is. Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate. - Jay (phone) On Jul 21, 2009, at 8:02 AM, "Randy Coleburn" wrote: >>> Jay K 7/21/2009 4:05 AM >>> >Bear in mind some features:> > do-pkg (via sysinfo) does a good job of finding compiler/linker > You can copy that, but I also intend to move it into the config files if I can. > Though not sure e.g. path/lib/include-search is easy there. > And I don't want the config files every time to launch a bunch of processes to do the probing. > Maybe move the logic to cm3 itself. Maybe. My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > sets the version defines when building cm3, by reading the version file > The python, .sh, and preexisting .cmd do that. You can copy the code out though. I thought the version information was built into the compiler? >Is a little more easily extended -- no builtin list of package groups, but not a big deal. >Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >Ditto for do-cm3-std.py wrapping do-pkg.py. This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. >The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >and then improved things by introducing pkginfo.txt. My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. >Some of the generalizations aren't useful. >I'm going to remove the purported support for PM3 and M3 from pylib.py for example. >My Python code is still missing a nifty feature that Olaf added to the .sh where you can >pass extra parameters on to cm3. My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. >Yeah we do need to filter out more packages. >The package list has grown since I last used the .cmd files and pylib.py has its own list, >so I might not be building those packages on any platform. >I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. >.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >Again you might want to try writing JScript. It is much more natural. It can be slow >but you aren't likely to notice here. And it is very portable to Windows. >You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 22 00:37:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 22:37:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> Message-ID: Correct. Unless this stuff is "well known" -- like the chmod values -- the code was wrong and/or highly platform specific, yet blithely did the same thing for all platforms. struct termio ws declared as merely an array of 500 char. Just an arbitrary size hoped to be large enough? Or known to be surely large enough? Or even exactly the right size? There was also a race condition in the initialization, typical, though arguably there still is. "Look at the code, not just checkin comments or the file extensions" I like to think to advise people. Except for .sh and .cmd, that I can indict just by extension. :) As I understand, when writing C code to interface to Modula-3, one has to really think about it before marking the interface as safe. For example, the C code I provided trusts the pointers it is given. So it is probably not safe. I would probably need to check the struct termios I get and compare them to the two known ones and only dereference them if it is one of them. NULL could also be deemed ok, as long as I silently did nothing with it, no dereference. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Tue, 21 Jul 2009 14:25:44 -0400 > CC: rcoleburn at scires.com; m3devel at elegosoft.com > > I assume the argument here is the same as for the POSIX interfaces. > > Sent from my iPhone > > On Jul 21, 2009, at 1:53 PM, jay.krell at cornell.edu wrote: > >> I might have left it able to be called safe. Honestly I look more >> for human verifiable safety and correctness and it lacked those >> before and now does not. If that coincides with machine verifable >> safety, great. Either way you need C here for correctness and >> safety. It isn't 'nasty'. Not using C here would be nasty. I think >> you have it backwards. UNLESS the sizes and constants here are well >> known but reading docs quickly I didn't see that. Unsafe does not >> imply not portable. >> >> - Jay (phone) >> >> On Jul 21, 2009, at 9:03 AM, Tony Hosking >> wrote: >> >>> Hear, hear! >>> >>> >>> Sent from my iPhone >>> >>> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >>> wrote: >>> >>>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>>> definition means it is not portable. >>>> Why though do we want to replace it by nasty C code where non- >>>> portable stuff can be easily hidden? This is Modula-3. Why not >>>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>>> cents.) >>>> --Randy >>>> >>>>>>> Jay Krell 7/21/2009 11:55 AM>>> >>>> CVSROOT:/usr/cvs >>>> Changes by:jkrell at birch.09/07/21 11:55:36 >>>> >>>> Added files: >>>> cm3/caltech-parser/term/src/: TermC.c >>>> >>>> Log message: >>>> initial copy of dangerous non portable Term.m3 to rewrite portably >>>> and have it do nothing silently on Win32 which should suffice, or >>>> if not, can probably be done better, specifically the MakeRaw >>>> function >>>> >>>> >>> From jay.krell at cornell.edu Wed Jul 22 00:39:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 22:39:34 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A6601D6.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> Message-ID: I use the Python all the time on various platforms. It works. The .cmds I wrote I rarely use, and then, only on Windows. I thought your list of failures would be down to just m3cc. What are they? - Jay ________________________________ > Date: Tue, 21 Jul 2009 17:59:47 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] status report on Windows XP > > > > > > > > Jay, > > > > Glad to hear the PkgInfo.txt is viable and being maintained. > > > > Right now, I just don't have the time and motivation to learn jscript. > > > > I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine. > > > > The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks. > > > > Regards, > > Randy > >>>> 7/21/2009 2:11 PM>>> > > Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform. > > > > The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it. > > > > You do have jscript installed and it is pretty easy to read and learn. > > > > pkginfo.txt is important and maintained, yes. > > I need to switch the python to it. > > > > Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is. > > > > Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate. > > > > - Jay (phone) > > > On Jul 21, 2009, at 8:02 AM, "Randy Coleburn"> wrote: > > > > > >>>> Jay K> 7/21/2009 4:05 AM>>> >>Bear in mind some features:> >> do-pkg (via sysinfo) does a good job of finding compiler/linker >> You can copy that, but I also intend to move it into the config files if I can. >> Though not sure e.g. path/lib/include-search is easy there. >> And I don't want the config files every time to launch a bunch of processes to do the probing. >> Maybe move the logic to cm3 itself. Maybe. > My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > > >> sets the version defines when building cm3, by reading the version file >> The python, .sh, and preexisting .cmd do that. You can copy the code out though. > I thought the version information was built into the compiler? > > >>Is a little more easily extended -- no builtin list of package groups, but not a big deal. >>Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >>Ditto for do-cm3-std.py wrapping do-pkg.py. > This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. > > >>The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >>and then improved things by introducing pkginfo.txt. > My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. > > >>Some of the generalizations aren't useful. >>I'm going to remove the purported support for PM3 and M3 from pylib.py for example. > >>My Python code is still missing a nifty feature that Olaf added to the .sh where you can >>pass extra parameters on to cm3. > My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. > > >>Yeah we do need to filter out more packages. >>The package list has grown since I last used the .cmd files and pylib.py has its own list, >>so I might not be building those packages on any platform. >>I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. > >>.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >>Again you might want to try writing JScript. It is much more natural. It can be slow >>but you aren't likely to notice here. And it is very portable to Windows. >>You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. > Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy > > From hosking at cs.purdue.edu Wed Jul 22 02:19:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 20:19:02 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A66005F.1E75.00D7.1@scires.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: I generally agree, but in this case we are probably dependent on a large number of C header files on the various different targets. Jay's efforts have reduced the burned of cloning C header files into Modula-3 interfaces. It is a fine line to tread though, and I think it is important to resist gratuitous rewrites into C code. In this case, I haven't had the chance to look at the code for Term.m3 and understand what is being attempted. On 21 Jul 2009, at 17:53, Randy Coleburn wrote: > Jay: > > I guess this topic is just a pet peeve of mine. > We tout Modula-3 as a systems programming language and that it has > all these great features that make it superior to languages that > lack them, yet when we "don't practice what we preach" and use > another language it weakens the argument. > > IMO, using C instead of Modula-3 is kind of like saying that we love > baseball, but we have to use soccer to play baseball the right way. > It just doesn't add up. > > I think we should always use Modula-3 in developing and enhancing > the CM3 system. > > I must also disagree with you and state that for a TRUE Modula-3 > fan, C is indeed "nasty." > > All that said, I haven't looked at the code in question here. I > simply commented on the idea of replacing M3 code with C code. > > Regards, > Randy > > >>> 7/21/2009 1:53 PM >>> > I might have left it able to be called safe. Honestly I look more for > human verifiable safety and correctness and it lacked those before and > now does not. If that coincides with machine verifable safety, great. > Either way you need C here for correctness and safety. It isn't > 'nasty'. Not using C here would be nasty. I think you have it > backwards. UNLESS the sizes and constants here are well known but > reading docs quickly I didn't see that. Unsafe does not imply not > portable. > > - Jay (phone) > > On Jul 21, 2009, at 9:03 AM, Tony Hosking > wrote: > > > Hear, hear! > > > > > > Sent from my iPhone > > > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > > wrote: > > > >> Granted, I see that Term.m3 is an UNSAFE module, so that by > >> definition means it is not portable. > >> Why though do we want to replace it by nasty C code where non- > >> portable stuff can be easily hidden? This is Modula-3. Why not > >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 > >> cents.) > >> --Randy > >> > >> >>> Jay Krell 7/21/2009 11:55 AM >>> > >> CVSROOT:/usr/cvs > >> Changes by:jkrell at birch.09/07/21 11:55:36 > >> > >> Added files: > >> cm3/caltech-parser/term/src/: TermC.c > >> > >> Log message: > >> initial copy of dangerous non portable Term.m3 to rewrite portably > >> and have it do nothing silently on Win32 which should suffice, or > >> if not, can probably be done better, specifically the MakeRaw > >> function > >> > >> > > > From jay.krell at cornell.edu Wed Jul 22 03:22:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 01:22:55 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: Until the kernels, libc, X-Windows, etc. are written in Modula-3, or come with Modula-3 *.i3 files provided by their maintainers, or perhaps completely stop changing, or perhaps we drop support for all but one target, all of which I predict to be never, it behooves us /significantly/ to interoperate with them via C. Otherwise you trade an impractical purist notion of using Modula-3 for portability and safety. The system is now tremendously more portable and safe with the replacement of a bunch of Modula-3 with far less portable clean safe C. It is true there is an extra layer when things are done this way, sometimes even extra copying. But it is worth it. Heck, it makes things more debuggable too because C tends to be more debuggable by gdb. Besides: The compiler front end is written in Modula-3. The garbage collector is written in Modula-3. The NT386 backend is written in Modula-3, and we should adapt that to all x86 targets. The compiler back-end is a //huge// piece of C (and M4, and Make, and Bourne shell...) The untraced heap is implemented in C. The "build scripts" are written in Bourne shell, Python, Cmd. They interact with a server written in at least Perl and C. You don't need the entire system to be in Modula-3 to prove that it is a "systems" language. You will never get there. Yes, I know people write web servers in other languages, including that cm3ide is essentially a web server written in Modula-3, but still, you won't get there. We should perhaps consider using the web server underpinnings of cm3ide to run modula3.elegosoft.com. Really. If it is close to already having the required functionality. We can actually have a bit more Modula-3 and less C. For example we could have our own untraced heap. We could implement Cstring.i3 ourselves in Modula-3. Besides all that, I've been using C a lot lately. I believe is far more tractable than most people think. Modula-3's safety and esp. its syntax get in my way. It isn't bad as, say, Java, but.. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Tue, 21 Jul 2009 20:19:02 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I generally agree, but in this case we are probably dependent on a > large number of C header files on the various different targets. > Jay's efforts have reduced the burned of cloning C header files into > Modula-3 interfaces. It is a fine line to tread though, and I think > it is important to resist gratuitous rewrites into C code. In this > case, I haven't had the chance to look at the code for Term.m3 and > understand what is being attempted. > > > On 21 Jul 2009, at 17:53, Randy Coleburn wrote: > >> Jay: >> >> I guess this topic is just a pet peeve of mine. >> We tout Modula-3 as a systems programming language and that it has >> all these great features that make it superior to languages that >> lack them, yet when we "don't practice what we preach" and use >> another language it weakens the argument. >> >> IMO, using C instead of Modula-3 is kind of like saying that we love >> baseball, but we have to use soccer to play baseball the right way. >> It just doesn't add up. >> >> I think we should always use Modula-3 in developing and enhancing >> the CM3 system. >> >> I must also disagree with you and state that for a TRUE Modula-3 >> fan, C is indeed "nasty." >> >> All that said, I haven't looked at the code in question here. I >> simply commented on the idea of replacing M3 code with C code. >> >> Regards, >> Randy >> >>>>> 7/21/2009 1:53 PM>>> >> I might have left it able to be called safe. Honestly I look more for >> human verifiable safety and correctness and it lacked those before and >> now does not. If that coincides with machine verifable safety, great. >> Either way you need C here for correctness and safety. It isn't >> 'nasty'. Not using C here would be nasty. I think you have it >> backwards. UNLESS the sizes and constants here are well known but >> reading docs quickly I didn't see that. Unsafe does not imply not >> portable. >> >> - Jay (phone) >> >> On Jul 21, 2009, at 9:03 AM, Tony Hosking >> wrote: >> >>> Hear, hear! >>> >>> >>> Sent from my iPhone >>> >>> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >>> wrote: >>> >>>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>>> definition means it is not portable. >>>> Why though do we want to replace it by nasty C code where non- >>>> portable stuff can be easily hidden? This is Modula-3. Why not >>>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>>> cents.) >>>> --Randy >>>> >>>>>>> Jay Krell 7/21/2009 11:55 AM>>> >>>> CVSROOT:/usr/cvs >>>> Changes by:jkrell at birch.09/07/21 11:55:36 >>>> >>>> Added files: >>>> cm3/caltech-parser/term/src/: TermC.c >>>> >>>> Log message: >>>> initial copy of dangerous non portable Term.m3 to rewrite portably >>>> and have it do nothing silently on Win32 which should suffice, or >>>> if not, can probably be done better, specifically the MakeRaw >>>> function >>>> >>>> >>> >> > From wagner at elegosoft.com Wed Jul 22 11:26:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 11:26:42 +0200 Subject: [M3devel] cm3ide HTTP server, was: Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: <20090722112642.vs5xve6934s8g4wk@mail.elegosoft.com> Quoting Jay K : > We should perhaps consider using the web server underpinnings of > cm3ide to run modula3.elegosoft.com. Really. If it is close to > already having the required functionality. No, it doesn't reach the area of complexity we usually expect in a web server nowadays. What we should do (which I intended to have done months ago :-/) is to setup a publicly accessible instance of the cm3ide GUI so people can play with it online. Some care must be taken though to not compromise our server... Anybody interested in doing this? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 22 16:06:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 16:06:45 +0200 Subject: [M3devel] tinderbox failures Message-ID: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Apart from four red boxes for new tinderbox clients, regression tests on niagara still fail: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248261714.32591 This used to work some days ago... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 16:28:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 14:28:30 +0000 Subject: [M3devel] tinderbox failures In-Reply-To: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Message-ID: Some of the new ones aren't terrible: LINUXLIBC6 failed the tests because it couldn't load dependent libraries. PPC_LINUX ran out of diskspace. SPARC32_LINUX looks ok. The problem on SOLgnu is it doesn't see the config file. Maybe my change yesterday will fix it? To always copy the config files? I'm very "timezone challenged". I never know when a Tinderbox run is in relation to my changes, and the changes column is no longer filled in since the server crash. :( How about we move cp_config_files earlier in upgrade.sh?? I can try that right now..I can't test it other than by watching the Tinderbox. If these are used with 5.4, hard to predict the result.. Go ahead with that? - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 16:06:45 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox failures > > Apart from four red boxes for new tinderbox clients, regression tests > on niagara still fail: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248261714.32591 > > This used to work some days ago... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 22 16:47:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 16:47:06 +0200 Subject: [M3devel] tinderbox failures In-Reply-To: References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Message-ID: <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> Quoting Jay K : > Some of the new ones aren't terrible: > LINUXLIBC6 failed the tests because it couldn't load dependent libraries. > PPC_LINUX ran out of diskspace. > SPARC32_LINUX looks ok. > > > The problem on SOLgnu is it doesn't see the config file. > Maybe my change yesterday will fix it? To always copy the config files? > I'm very "timezone challenged". I never know when a Tinderbox > run is in relation to my changes, and the changes column is no longer > filled in since the server crash. :( That's one of the things that just work in Hudson. I thought the release built was after your changes, or I wouldn't have sent the mail yet. > How about we move cp_config_files earlier in upgrade.sh?? > I can try that right now..I can't test it other than > by watching the Tinderbox. If these are used with 5.4, hard to predict > the result.. Go ahead with that? I don't understand what you want to achieve with that. But I cannot check right now. 5.4 has just one single cm3.cfg file, and no sub dirs. I told you we'd need to cope with that. But then it seems to have worked for FreeBSD on Hudson: see http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/changes and http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/16/consoleFull which start with === 2009-07-21 23:17:10 build cm3 core in /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4 with last release /ad0e/home/hudson/work/cm3-inst/luthien/rel-5.4.0 Critical Mass Modula-3 version 5.4.0 last updated: 2006-10-11 configuration: /ad0e/home/hudson/work/cm3-inst/luthien/current--release-build/bin/cm3.cfg I don't know if that's conclusive though... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 17:06:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 15:06:10 +0000 Subject: [M3devel] tinderbox failures In-Reply-To: <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> Message-ID: I need(ed) to read through/understand the scripts more. Yes, agreed, the configuration is best left alone when the preexisting cm3 is used -- which is always, now that I read it, it is copied either from lastok or last-rel. It should only be upgraded in association with cm3 being upgraded. Unless as a potshot to fix things, since the config files are fairly good and portable -- I think most of the stuff I removed was for pre-5.4 compat. Anyway, you can see in the log all the cp commands failed, because -v is not understood. Let's see how it goes now. My three new ones should go better, freed /lots/ of diskspace, made sure there were .a files in the lastok hand built installs, though odd that it should matter, the tests should use the new stuff. We'll see. I think I ran one of them lastrel by accident. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 16:47:06 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] tinderbox failures > > Quoting Jay K : > >> Some of the new ones aren't terrible: >> LINUXLIBC6 failed the tests because it couldn't load dependent libraries. >> PPC_LINUX ran out of diskspace. >> SPARC32_LINUX looks ok. >> >> >> The problem on SOLgnu is it doesn't see the config file. >> Maybe my change yesterday will fix it? To always copy the config files? >> I'm very "timezone challenged". I never know when a Tinderbox >> run is in relation to my changes, and the changes column is no longer >> filled in since the server crash. :( > > That's one of the things that just work in Hudson. > I thought the release built was after your changes, or I wouldn't have > sent the mail yet. > >> How about we move cp_config_files earlier in upgrade.sh?? >> I can try that right now..I can't test it other than >> by watching the Tinderbox. If these are used with 5.4, hard to predict >> the result.. Go ahead with that? > > I don't understand what you want to achieve with that. > But I cannot check right now. > > 5.4 has just one single cm3.cfg file, and no sub dirs. I told you > we'd need to cope with that. > > But then it seems to have worked for FreeBSD on Hudson: > > see > http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/changes > and > http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/16/consoleFull > > which start with > > === 2009-07-21 23:17:10 build cm3 core in > /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4 with last > release /ad0e/home/hudson/work/cm3-inst/luthien/rel-5.4.0 > Critical Mass Modula-3 version 5.4.0 > last updated: 2006-10-11 > configuration: > /ad0e/home/hudson/work/cm3-inst/luthien/current--release-build/bin/cm3.cfg > > I don't know if that's conclusive though... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From eiserlohpp at yahoo.com Wed Jul 22 17:53:09 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 22 Jul 2009 08:53:09 -0700 (PDT) Subject: [M3devel] m3middle compile failure (overrides) Message-ID: <982128.58200.qm@web56808.mail.re3.yahoo.com> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, but failed. The m3overrides file for m3middle, was recently changed, and now causes compilation failure. WAS: if not defined("BOOT") override("m3core", ROOT & "/m3-libs") override("libm3", ROOT & "/m3-libs") end NOW: include(ROOT & "/m3overrides") It is looking in the root of the entire source tree, for a non-existent m3overrides file, and quake rightly complains. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Wed Jul 22 17:55:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 15:55:46 +0000 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <982128.58200.qm@web56808.mail.re3.yahoo.com> References: <982128.58200.qm@web56808.mail.re3.yahoo.com> Message-ID: The file exists. cvs -z3 upd - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 08:53:09 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3middle compile failure (overrides) > > > I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, > but failed. > > > The m3overrides file for m3middle, was recently changed, > and now causes compilation failure. > > WAS: > if not defined("BOOT") > override("m3core", ROOT & "/m3-libs") > override("libm3", ROOT & "/m3-libs") > end > > > NOW: > include(ROOT & "/m3overrides") > > > It is looking in the root of the entire source tree, > for a non-existent m3overrides file, and quake rightly > complains. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Wed Jul 22 18:02:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 16:02:03 +0000 Subject: [M3devel] NT386 problem with C runtime/tools versions Message-ID: I just discovered that..well..if the user has a different version of Visual C++ tools/libraries than the distribution is built with..many scenarios don't work -- e.g. not using build_standalone. It should have worked better. Until/unless I work out something better here, I'd suggest we build multiple releases, one for each likely to be used toolset. 8.0/2005 and 9.0/2008 are probably a good mix currently. I guess in some ways this isn't surprising, IF any of the Modula-3 libraries traffic in either FILE* (fopen/fread/fwrite/fclose) or "int file" (open/close/read/write), but they might not. Or malloc/free, which they might. We might consider ensuring the untraced heap is via HeapAlloc(GetProcessHeap()) in order to be independent of the C runtime -- in general the C runtime dependencies probably can/should be limited, but this is another topic, another release. - Jay From jay.krell at cornell.edu Wed Jul 22 18:04:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 16:04:15 +0000 Subject: [M3devel] Tinderbox should always run tests? Message-ID: Olaf, is there any reason every Tinderbox run shouldn't run the tests? - Jay From rcoleburn at scires.com Wed Jul 22 18:06:16 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 22 Jul 2009 12:06:16 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> Message-ID: <4A670075.1E75.00D7.1@scires.com> Jay: I tried the python script, but it did not work for me. I installed python 2.6.2. Should I have used 3.1? There was a note about 3.1 not being compatible with some stuff. I discovered a problem in the PkgInfo.txt where the 3 juno packages didn't have the path "juno-2/" prepended, so I've fixed that and I've updated my local CVS copy to be current with the repository, and rebuilt everything using my script, e.g. "do-cm3 all clean buildship". The only packages from PkgInfo.txt that fail to build (i.e., cm3 exits with errorlevel >0) on Windows now are: m3-sys/m3cc caltech-parser/parserlib/parserlib/test Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on that package fails. Regards, Randy Coleburn >>> Jay K 7/21/2009 6:39 PM >>> I use the Python all the time on various platforms. It works. The .cmds I wrote I rarely use, and then, only on Windows. I thought your list of failures would be down to just m3cc. What are they? - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Wed Jul 22 18:34:10 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 22 Jul 2009 09:34:10 -0700 (PDT) Subject: [M3devel] m3middle compile failure (overrides) Message-ID: <817070.81781.qm@web56807.mail.re3.yahoo.com> Hi Jay, Peter said: >I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, but failed. Jay said: >The file exists. >cvs -z3 upd > >- Jay No it does not exist in the tarball. When I did a cvs update in my CVS tree, yes it is there, but not in the tarball. I downloaded a tarball, and attempted to build in that. The scripts used to build the tarballs look like they explicitly builds a list of files/directories to include and exclude. The toplevel m3overrides file is not listed in the build script, so does not get into ".tar-include". You added a file to the top level of the source tree, and the build script (make-src-dist-all.sh, and family) were not updated. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed Jul 22 18:56:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 18:56:48 +0200 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <817070.81781.qm@web56807.mail.re3.yahoo.com> References: <817070.81781.qm@web56807.mail.re3.yahoo.com> Message-ID: <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> Well, there are always side-effects to this kind of global changes. Jay, please fix the scripts. Thanks, Olaf Quoting Peter Eiserloh : > Hi Jay, > > > Peter said: >> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, > but failed. > > > Jay said: >> The file exists. >> cvs -z3 upd >> >> - Jay > > No it does not exist in the tarball. When I did a cvs update > in my CVS tree, yes it is there, but not in the tarball. > I downloaded a tarball, and attempted to build in that. > > The scripts used to build the tarballs look like they > explicitly builds a list of files/directories to include > and exclude. The toplevel m3overrides file is not listed > in the build script, so does not get into ".tar-include". > > You added a file to the top level of the source tree, and > the build script (make-src-dist-all.sh, and family) were > not updated. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 22 19:00:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 19:00:12 +0200 Subject: [M3devel] Tinderbox should always run tests? In-Reply-To: References: Message-ID: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> Quoting Jay K : > Olaf, is there any reason every Tinderbox run shouldn't run the tests? We don't want to run them both after the release- and the lastok- build (to save resources). It should be no problem to adapt the scripts for any specific setup (like I did on birch). If you don't run the release build, you should of course add running the tests after the lastok build. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 21:47:37 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 22 Jul 2009 12:47:37 -0700 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A670075.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> Message-ID: <050B1665-CAF7-4520-9613-B5EB0AD028E2@hotmail.com> I tried python 3.x once it didn't work. I stay with 2.x for now. - clean often does not work, I use realclean. I will check the test directory. You should be able to filter out m3cc. I might. - Jay (phone) On Jul 22, 2009, at 9:06 AM, "Randy Coleburn" wrote: > Jay: > > I tried the python script, but it did not work for me. I installed > python 2.6.2. Should I have used 3.1? There was a note about 3.1 > not being compatible with some stuff. > > I discovered a problem in the PkgInfo.txt where the 3 juno packages > didn't have the path "juno-2/" prepended, so I've fixed that and > I've updated my local CVS copy to be current with the repository, > and rebuilt everything using my script, e.g. "do-cm3 all clean > buildship". > > The only packages from PkgInfo.txt that fail to build (i.e., cm3 > exits with errorlevel >0) on Windows now are: > m3-sys/m3cc > caltech-parser/parserlib/parserlib/test > > Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on > that package fails. > > Regards, > Randy Coleburn > > >>> Jay K 7/21/2009 6:39 PM >>> > > I use the Python all the time on various platforms. It works. > The .cmds I wrote I rarely use, and then, only on Windows. > I thought your list of failures would be down to just m3cc. What are > they? > > - Jay From jay.krell at cornell.edu Wed Jul 22 22:35:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 20:35:36 +0000 Subject: [M3devel] Tinderbox should always run tests? In-Reply-To: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> References: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> Message-ID: Next question -- how to get the tests status to appear? I see the sample at the end of defs.sh -- call main | logfilter | mail. But how do integrate that with ./tinderbox-build cm3.build? Call them both one after the other? I don't see relevant tinderbox or cm3 in /etc/cron* /etc/cron*/* on birch. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 19:00:12 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: Tinderbox should always run tests? > > Quoting Jay K : > >> Olaf, is there any reason every Tinderbox run shouldn't run the tests? > > We don't want to run them both after the release- and the lastok- > build (to save resources). It should be no problem to adapt the > scripts for any specific setup (like I did on birch). > > If you don't run the release build, you should of course add running > the tests after the lastok build. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 22 22:37:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 20:37:15 +0000 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> References: <817070.81781.qm@web56807.mail.re3.yahoo.com> <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> Message-ID: oops, sorry, should be ok for the next set. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 18:56:48 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3middle compile failure (overrides) > > Well, there are always side-effects to this kind of global changes. > Jay, please fix the scripts. > > Thanks, > > Olaf > > Quoting Peter Eiserloh : > >> Hi Jay, >> >> >> Peter said: >>> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, >> but failed. >> >> >> Jay said: >>> The file exists. >>> cvs -z3 upd >>> >>> - Jay >> >> No it does not exist in the tarball. When I did a cvs update >> in my CVS tree, yes it is there, but not in the tarball. >> I downloaded a tarball, and attempted to build in that. >> >> The scripts used to build the tarballs look like they >> explicitly builds a list of files/directories to include >> and exclude. The toplevel m3overrides file is not listed >> in the build script, so does not get into ".tar-include". >> >> You added a file to the top level of the source tree, and >> the build script (make-src-dist-all.sh, and family) were >> not updated. >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 23 07:55:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 07:55:03 +0200 Subject: [M3devel] NT386 problem with C runtime/tools versions In-Reply-To: References: Message-ID: <20090723075503.bzhj08ps004c00oc@mail.elegosoft.com> Quoting Jay K : > > I just discovered that..well..if the user has a different version of > Visual C++ tools/libraries than the distribution is built > with..many scenarios don't work -- e.g. not using build_standalone. > It should have worked better. > Until/unless I work out something better here, I'd suggest we build > multiple releases, one for each likely to be used toolset. 8.0/2005 > and 9.0/2008 are probably a good mix currently. > > > I guess in some ways this isn't surprising, IF any of the Modula-3 > libraries traffic in either FILE* (fopen/fread/fwrite/fclose) or > "int file" (open/close/read/write), but they might not. Or > malloc/free, which they might. We might consider ensuring the > untraced heap is via HeapAlloc(GetProcessHeap()) in order to be > independent of the C runtime -- in general the C runtime > dependencies probably can/should be limited, but this is another > topic, another release. Please add these topics in trac to the roadmap for the next release. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 11:34:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 11:34:50 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A670075.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> Message-ID: <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Quoting Randy Coleburn : > The only packages from PkgInfo.txt that fail to build (i.e., cm3 > exits with errorlevel >0) on Windows now are: > m3-sys/m3cc > caltech-parser/parserlib/parserlib/test > > Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on > that package fails. Wrong (missing) depencencies or heavy quake hacking? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 15:42:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 15:42:53 +0200 Subject: [M3devel] CM3 Release Engineering Status Message-ID: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> I updated the roadmap in our trac https://projects.elego.de/cm3/roadmap and created several tickets, see https://projects.elego.de/cm3/timeline This morning I moved the RC2 tag to a position which should now be almost stable (hopefully), but I don't really know yet. Many tests are pending. Any help on resolving the tickets and other issues not yet recorded in trac will be appreciated. I'm not sure if we can cope with all the tasks during the weekend; I'll move the milestone date if necessary. Please write a ticket for every issue that is related to one of the release milestones (one on the formsedit crash is still missing, for example). Again, if you need access to trac, let me know; the web admin GUI is broken and I need to add accounts and passwords from the command line. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jul 23 17:10:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 23 Jul 2009 11:10:42 -0400 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> Message-ID: <4A6844E7.1E75.00D7.1@scires.com> Olaf: My browser is reporting a problem with the security certificate used for these web pages. I can work on "install.cmd" for you. I haven't had any crash with cm3ide. If someone can give details, I'll try to check into it. With regard to #1007, I already sent in the script you requested. Here it is again. Your script can be expressed in Windows .CMD format as follows: REM ---BEGIN--- @echo off for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p goto End :ShipIt echo ...shipping %1... pushd %1 cm3 -ship %SHIPARGS% popd echo. goto :EOF :End echo done @echo on REM ---END--- Of course, the REM lines at the beginning/end are optional, I just put them there to show start/end of the script. Also, you would want to replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of folders to be processed. You can separate them by blank spaces or semi-colons, but if you have a path with an embedded space, you will need to put double quotes around the path. FYI: If your list of paths is in a text file, there is another form of the FOR command that would work to process the list from that file. I don't mind writing .CMD files, so if you and Jay want some help in this area, I am willing to volunteer. Regards, Randy Coleburn >>> Olaf Wagner 7/23/2009 9:42 AM >>> I updated the roadmap in our trac https://projects.elego.de/cm3/roadmap and created several tickets, see https://projects.elego.de/cm3/timeline This morning I moved the RC2 tag to a position which should now be almost stable (hopefully), but I don't really know yet. Many tests are pending. Any help on resolving the tickets and other issues not yet recorded in trac will be appreciated. I'm not sure if we can cope with all the tasks during the weekend; I'll move the milestone date if necessary. Please write a ticket for every issue that is related to one of the release milestones (one on the formsedit crash is still missing, for example). Again, if you need access to trac, let me know; the web admin GUI is broken and I need to add accounts and passwords from the command line. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 23 17:21:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 23 Jul 2009 15:21:13 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <4A6844E7.1E75.00D7.1@scires.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: > My browser is reporting a problem with the security certificate used for these web pages. I reported that, for IE8. Workaround: Firefox or Opera. - Jay From wagner at elegosoft.com Thu Jul 23 18:13:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 18:13:14 +0200 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <4A6844E7.1E75.00D7.1@scires.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: <20090723181314.3csixgnyr4o84gsc@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > My browser is reporting a problem with the security certificate used > for these web pages. That may well be. I think you should be able to ignore those warnings. Admin resources are scarce currently, not to say non-existent :-/ I've got no problems with trac access with either Firefox or Opera. > I can work on "install.cmd" for you. > > I haven't had any crash with cm3ide. If someone can give details, I'll > try to check into it. > > With regard to #1007, I already sent in the script you requested. Here > it is again. I noticed you had send that, but haven't come round to include the generation in make-dist.sh. I'm rather collecting and recording all the tasks that need to be done (in spare minutes at my paid work). Thanks again, Olaf > Your script can be expressed in Windows .CMD format as follows: > > REM ---BEGIN--- > @echo off > for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p > goto End > > :ShipIt > echo ...shipping %1... > pushd %1 > cm3 -ship %SHIPARGS% > popd > echo. > goto :EOF > > :End > echo done > @echo on > REM ---END--- > > Of course, the REM lines at the beginning/end are optional, I just put > them there to show start/end of the script. Also, you would want to > replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of > folders to be processed. You can separate them by blank spaces or > semi-colons, but if you have a path with an embedded space, you will > need to put double quotes around the path. > > FYI: If your list of paths is in a text file, there is another form of > the FOR command that would work to process the list from that file. > > I don't mind writing .CMD files, so if you and Jay want some help in > this area, I am willing to volunteer. > > Regards, > Randy Coleburn > >>>> Olaf Wagner 7/23/2009 9:42 AM >>> > I updated the roadmap in our trac > > https://projects.elego.de/cm3/roadmap > > and created several tickets, see > > https://projects.elego.de/cm3/timeline > > This morning I moved the RC2 tag to a position which should > now be almost stable (hopefully), but I don't really know yet. > Many tests are pending. > > Any help on resolving the tickets and other issues not yet > recorded in trac will be appreciated. I'm not sure if we can cope > with all the tasks during the weekend; I'll move the milestone > date if necessary. > > Please write a ticket for every issue that is related to one of > the release milestones (one on the formsedit crash is still missing, > for example). > > Again, if you need access to trac, let me know; the web admin GUI > is broken and I need to add accounts and passwords from the command > line. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 18:16:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 18:16:08 +0200 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Quoting Jay K : > >> My browser is reporting a problem with the security certificate >> used for these web pages. > > I reported that, for IE8. > Workaround: Firefox or Opera. And you found no way to turn it off in Internet Explorer? Surely Microsoft cannot assume that the whole Internet is officially certified? We'd need to raise some funds if we wanted to do that for cm3... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 06:08:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 04:08:31 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Thu, 23 Jul 2009 18:16:08 +0200 > From: wagner > To: jay > CC: m3devel; m3-support; admins > Subject: RE: [M3devel] CM3 Release Engineering Status > > Quoting Jay K : > >> >>> My browser is reporting a problem with the security certificate >>> used for these web pages. >> >> I reported that, for IE8. >> Workaround: Firefox or Opera. > > And you found no way to turn it off in Internet Explorer? > > Surely Microsoft cannot assume that the whole Internet is > officially certified? We'd need to raise some funds if we wanted > to do that for cm3... > > Olaf I hadn't but now I have. The first error you get: There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority. The security certificate presented by this website was issued for a different website's address. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). More information You only get once per running IE and browsing to the site. Not a big deal. You can maybe add the certificate to some setting to ignore in future. I think this is the part you (Olaf and Randy) are referring to. The bigger problem is that once you ignore this, every single click in Trac brings up another message, about displaying a mix of secure/insecure content. I just found the fix to that: http://blogs.msdn.com/askie/archive/2009/05/14/mixed-content-and-internet-explorer-8-0.aspx A setting to for mixed content: enable, disable, prompt. Change from prompt to enable. I'm not sure if you can scope it to just modula3/elegosoft (maybe you can make a custom zone, add the sites, change the settings?) It sounds like it is only for IE8. That for IE7 there is no fix? Maybe for IE6 there was no prompt? I'm using IE8. Maybe you are supposed to replicate all the insecure stuff on the secure site? I don't know. - Jay From jay.krell at cornell.edu Fri Jul 24 06:45:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 04:45:42 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: > Surely Microsoft cannot assume that the whole Internet is > officially certified? We'd need to raise some funds if we wanted > to do that for cm3... > > Olaf How much? It looks like..verisign..cheapest option.. $600/year $1100/2 years (save $100) $1600/3 years (save $200) good enough? Can six people each put up $100, check payable to Olaf, he volunteers his time (or make it seven people, or $110 each), and we'll worry about it again in a year? I can. Or ignore it? Double the price for 128bit instead of 40bit. I don't understand the "extended validation, gren address bar". Shop around maybe it is availabe cheaper? Or just ignore it? Maybe they offer a discount for open source projects? I'll poke around a bit more.. GoDaddy seems to offer much better. Free for a year for open source projects, 256 bit, a $30 value. A $30 value, hm. So..if you don't want the bureacracy of being an official open source project.. They really do offer stuff starting at $30/year. Their most expensive option seems to be $240/year. Multi-year discounts range from 10% to 25%. So..just $30/year? Or free due to being open source? This sounds more viable and maybe worthwhile. Or just ignore it? - Jay From wagner at elegosoft.com Fri Jul 24 09:55:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 09:55:34 +0200 Subject: [M3devel] Trusted certificates for Elego's web services In-Reply-To: References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> I'll put this topic on the agenda of our next infrastructure meeting at Elego. It will be some time, since our 'prime administrator' is on a long vacation in the US. I've never really understood why I should feel more secure if a large enterprise whose procedures I don't know and can neither examine nor validate certifies that I bought just that certificate from them. Nor do I see it really necessary for those who don't engage in online shopping or trading. I do see that it's an interesting business though (financial perspective). However, it seems to become more and more expected that one has certificates from a trusted issuer, so it will affect all Elego customers, too. We'll have to get certificates for all our web servers, which will then include the CM3 one. I'll let you know if we can take over the costs :-) Let's ignore this issue for while... Olaf Quoting Jay K : >> Surely Microsoft cannot assume that the whole Internet is >> officially certified? We'd need to raise some funds if we wanted >> to do that for cm3... >> >> Olaf > > How much? > > > It looks like..verisign..cheapest option.. > $600/year > $1100/2 years (save $100) > $1600/3 years (save $200) > > good enough? > > Can six people each put up $100, check payable to Olaf, > he volunteers his time (or make it seven people, or $110 each), and we'll > worry about it again in a year? > I can. > > Or ignore it? > > Double the price for 128bit instead of 40bit. > > I don't understand the "extended validation, gren address bar". > > Shop around maybe it is availabe cheaper? > > Or just ignore it? > > Maybe they offer a discount for open source projects? > > I'll poke around a bit more.. > > > GoDaddy seems to offer much better. > Free for a year for open source projects, 256 bit, a $30 value. > A $30 value, hm. > > > So..if you don't want the bureacracy of being an official open > source project.. > They really do offer stuff starting at $30/year. > Their most expensive option seems to be $240/year. > Multi-year discounts range from 10% to 25%. > > > So..just $30/year? > Or free due to being open source? > > This sounds more viable and maybe worthwhile. Or just ignore it? > > > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 10:53:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:53:24 +0000 Subject: [M3devel] Hudson errors in cvs upd. Message-ID: A SCM change trigger started this job Building on master [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" U m3-libs/libm3/src/random/m3makefile U m3-libs/m3core/src/Csupport/m3makefile U m3-libs/m3core/src/time/POSIX/m3makefile ? m3-libs/unittest/AMD64_LINUX U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN ... cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' U m3-sys/m3middle/src/Target.i3 U m3-sys/m3middle/src/Target.m3 U m3-sys/m3middle/src/m3makefile U scripts/pkgmap.sh ? scripts/PKGS SCM check out aborted Finished: FAILURE I know I was thinking of deleting those directories but I don't think I did. - Jay From jay.krell at cornell.edu Fri Jul 24 10:57:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:57:09 +0000 Subject: [M3devel] Hudson errors out of diskspace Message-ID: Here's another: new source -> compiling ../FreeBSD4/cm3unix.c ../FreeBSD4/cm3unix.c:3: fatal error: error writing to /var/tmp/ccVwJXWF.s: No space left on device Hudson is looking like a big improvement though -- the last success, last failure columns, the list of changes in a build, the quick access to the full output. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: Hudson errors in cvs upd. > Date: Fri, 24 Jul 2009 08:53:24 +0000 > > > A SCM change trigger started this job > Building on master > [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" > U m3-libs/libm3/src/random/m3makefile > U m3-libs/m3core/src/Csupport/m3makefile > U m3-libs/m3core/src/time/POSIX/m3makefile > ? m3-libs/unittest/AMD64_LINUX > U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN > ... > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' > U m3-sys/m3middle/src/Target.i3 > U m3-sys/m3middle/src/Target.m3 > U m3-sys/m3middle/src/m3makefile > U scripts/pkgmap.sh > ? scripts/PKGS > SCM check out aborted > Finished: FAILURE > > > I know I was thinking of deleting those directories but I don't think I did. > > > - Jay From jay.krell at cornell.edu Fri Jul 24 10:57:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:57:50 +0000 Subject: [M3devel] Hudson errors out of diskspace Message-ID: also: /var/tmp/hudson46743.sh: line 11: /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4/scripts/do-cm3-all.sh: No such file or directory could be related to out of diskspace though. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: RE: Hudson errors out of diskspace > Date: Fri, 24 Jul 2009 08:57:09 +0000 > > > Here's another: > > > new source -> compiling ../FreeBSD4/cm3unix.c > ../FreeBSD4/cm3unix.c:3: fatal error: error writing to /var/tmp/ccVwJXWF.s: No space left on device > > > Hudson is looking like a big improvement though -- the last success, last failure columns, the list of changes in a build, the quick access to the full output. > > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; wagner at elegosoft.com >> Subject: Hudson errors in cvs upd. >> Date: Fri, 24 Jul 2009 08:53:24 +0000 >> >> >> A SCM change trigger started this job >> Building on master >> [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" >> U m3-libs/libm3/src/random/m3makefile >> U m3-libs/m3core/src/Csupport/m3makefile >> U m3-libs/m3core/src/time/POSIX/m3makefile >> ? m3-libs/unittest/AMD64_LINUX >> U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN >> ... >> cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' >> cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' >> U m3-sys/m3middle/src/Target.i3 >> U m3-sys/m3middle/src/Target.m3 >> U m3-sys/m3middle/src/m3makefile >> U scripts/pkgmap.sh >> ? scripts/PKGS >> SCM check out aborted >> Finished: FAILURE >> >> >> I know I was thinking of deleting those directories but I don't think I did. >> >> >> - Jay From stsp at elego.de Fri Jul 24 11:09:16 2009 From: stsp at elego.de (Stefan Sperling) Date: Fri, 24 Jul 2009 10:09:16 +0100 Subject: [M3devel] Trusted certificates for Elego's web services In-Reply-To: <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> Message-ID: <20090724090916.GC3671@jack.stsp.name> On Fri, Jul 24, 2009 at 09:55:34AM +0200, Olaf Wagner wrote: > We'll have to get certificates for all our web servers, which will > then include the CM3 one. I'll let you know if we can take over the > costs :-) > > Let's ignore this issue for while... There are local certificate issuers in Germany, too. E.g. Deutsche Telekom does it and their root CA even made it into Firefox now: https://bugzilla.mozilla.org/show_bug.cgi?id=378882 They might still be operating as opaquely as Verisign but maybe they are less expensive. And they'd probably be less complicated for elego to deal with than any issuer in the US. They've also signed certs for DFN members (German universities and research institutions). E.g. if you go here you can see a chain going up to Telekom: https://webmail.spline.inf.fu-berlin.de/ >>> Surely Microsoft cannot assume that the whole Internet is >>> officially certified? I have a feeling they'd like to, but more in terms of who controls the procotols being used on the net, not necessarily with respect to SSL certs. That said, newer Firefox versions have also been pushing the user experience with self-signed certs far down in an attempt to get website admins to get their certs signed. Stefan From wagner at elegosoft.com Fri Jul 24 11:44:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 11:44:38 +0200 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: References: Message-ID: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Quoting Jay K : > Here's another: > > new source -> compiling ../FreeBSD4/cm3unix.c > ../FreeBSD4/cm3unix.c:3: fatal error: error writing to > /var/tmp/ccVwJXWF.s: No space left on device That was on my home machine because core dumps from m3tests were accumulating in /var/tmp. I've now set the core dump limit to 0 for those jobs. > Hudson is looking like a big improvement though -- the last success, > last failure columns, the list of changes in a build, the quick > access to the full output. Yes. I've been using it for about half a year now, and apart from the fact that it's resource hungry and sometimes slow, it's easy to use and configure. And you find a plug-in for almost everything. Since yesterday afternoon all necessary plug-ins for interaction with other servers should be installed. I've just moved the crontab jobs from user m3 on birch to hudson, see http://hudson.modula3.com:8080/view/m3-www-support/. My network connection is very unstable currently, so more failures are to be expected. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 12:44:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 10:44:06 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure Message-ID: I'm seeing wierd stuff. On PPC_LINUX. Compiling some files hangs. Such as M3Front.m3. It is actually looping forever in Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") which, you know, other than feeding it bad data, or corrupting its stack when it calls out to our lock/unlock, we can't mess up. I can watch what strings it gets on other systems and/or make a standalone case that hangs. While investigating this I hit control-c on a cm3 and hit: new source -> compiling SchedulerPosix.i3 (hung here) *** *** runtime error: *** failed. *** file "..\src\runtime\common\RTCollector.m3", line 1087 *** Aborted PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = BEGIN WHILE h < he DO line 1087 Maybe we don't deal with control-c at arbitrary points?? I was able to reproduce this assertion failure twice in a row.. though it moved to line 1089 the second time. PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = BEGIN WHILE h < he DO IF h.gray THEN line 1089 I verified that the hang compiling SchedulerPosix.i3 is also related to floating point conversion. This time in m3_dtoa. I will look further. Maybe my config file changes..but seems odd.. - Jay - Jay From jay.krell at cornell.edu Fri Jul 24 12:48:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 10:48:09 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: References: Message-ID: sorry, nevermind. It reproed on SOLgnu and then I found the problem. It's good to test little and big endian systems. I had broken all big endian systems. Should be ok now. I'll proceed to try to repro the formsedit crash. :) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 24 Jul 2009 10:44:06 +0000 > Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure > > > I'm seeing wierd stuff. > > On PPC_LINUX. From jay.krell at cornell.edu Fri Jul 24 13:41:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 11:41:25 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Message-ID: This should be fixed now. I assume it was broken on all platforms. -clean doesn't work well. Maybe time to make -clean just do the same as -realclean? - Jay ---------------------------------------- > Date: Thu, 23 Jul 2009 11:34:50 +0200 > From: wagner@ > To: m3devel@ > Subject: Re: [M3devel] status report on Windows XP > > Quoting Randy Coleburn : > >> The only packages from PkgInfo.txt that fail to build (i.e., cm3 >> exits with errorlevel>0) on Windows now are: >> m3-sys/m3cc >> caltech-parser/parserlib/parserlib/test >> >> Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on >> that package fails. > > Wrong (missing) depencencies or heavy quake hacking? > > Olaf > -- From wagner at elegosoft.com Fri Jul 24 13:56:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 13:56:15 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Message-ID: <20090724135615.n9htefpvkw4gogw8@mail.elegosoft.com> Quoting Jay K : > > This should be fixed now. > I assume it was broken on all platforms. > -clean doesn't work well. > Maybe time to make -clean just do the same as -realclean? I wouldn't mind that. Perhaps others do? Olaf > ---------------------------------------- >> Date: Thu, 23 Jul 2009 11:34:50 +0200 >> From: wagner@ >> To: m3devel@ >> Subject: Re: [M3devel] status report on Windows XP >> >> Quoting Randy Coleburn : >> >>> The only packages from PkgInfo.txt that fail to build (i.e., cm3 >>> exits with errorlevel>0) on Windows now are: >>> m3-sys/m3cc >>> caltech-parser/parserlib/parserlib/test >>> >>> Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on >>> that package fails. >> >> Wrong (missing) depencencies or heavy quake hacking? >> >> Olaf >> -- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 14:04:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 12:04:42 +0000 Subject: [M3devel] bourne shell error on Solaris tinderbox Message-ID: Tinderbox on Solaris: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? unexpected Perl or Python would be more portable perhaps. Or Modula-3? (Seriously: Python). - Jay From wagner at elegosoft.com Fri Jul 24 15:17:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 15:17:07 +0200 Subject: [M3devel] bourne shell error on Solaris tinderbox In-Reply-To: References: Message-ID: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> Quoting Jay K : > Tinderbox on Solaris: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 > > /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? > unexpected Sorry for that. Solaris has ksh, which understands POSIX command substitution, but other systems won't have that. Can we assume bash, or should I just replace all $() by backquotes again? > Perl or Python would be more portable perhaps. Or Modula-3? > (Seriously: Python). I don't want to have that big dependency for all tests... Otherwise I'd agree: always use Python if possible. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jul 24 16:06:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 24 Jul 2009 10:06:52 -0400 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: References: Message-ID: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> Yeah, I don't think control C works reasonably for all points in GC. Perhaps just eliminate the signal handler? Not sure. On 24 Jul 2009, at 06:44, Jay K wrote: > > I'm seeing wierd stuff. > > On PPC_LINUX. > > Compiling some files hangs. > Such as M3Front.m3. > > It is actually looping forever in > > Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") > > > which, you know, other than feeding it bad data, or corrupting > its stack when it calls out to our lock/unlock, we can't mess up. > > > I can watch what strings it gets on other systems and/or make > a standalone case that hangs. > > > While investigating this I hit control-c on a cm3 and hit: > > > new source -> compiling SchedulerPosix.i3 (hung here) > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > Aborted > > > > PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = > BEGIN > WHILE h < he DO > > line 1087 > > > Maybe we don't deal with control-c at arbitrary points?? > > > I was able to reproduce this assertion failure twice in a row.. > though it moved to line 1089 the second time. > > > > PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = > BEGIN > WHILE h < he DO > > > IF h.gray THEN > line 1089 > > > I verified that the hang compiling SchedulerPosix.i3 is also related > to floating point conversion. > This time in m3_dtoa. > > > I will look further. > Maybe my config file changes..but seems odd.. > > - Jay > > > - Jay > > From jay.krell at cornell.edu Fri Jul 24 16:08:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 14:08:08 +0000 Subject: [M3devel] bourne shell error on Solaris tinderbox In-Reply-To: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> References: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> Message-ID: Whatever works automatically or with little documented/errored fuss. (use #!/bin/bash and there'll be a clear error.) I doubt bash is on most systems by default. I figure if you have to use something that isn't installed by default, might as well be Python. (Esp. once I get it working on MIPS64_OPENBSD! Probably just have to turn off libffi.) - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 15:17:07 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: bourne shell error on Solaris tinderbox > > Quoting Jay K : > >> Tinderbox on Solaris: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 >> >> /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? >> unexpected > > Sorry for that. Solaris has ksh, which understands POSIX command > substitution, but other systems won't have that. > Can we assume bash, or should I just replace all $() by backquotes > again? > >> Perl or Python would be more portable perhaps. Or Modula-3? >> (Seriously: Python). > > I don't want to have that big dependency for all tests... > Otherwise I'd agree: always use Python if possible. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 24 16:11:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 14:11:41 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> References: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> Message-ID: Right..so I had a big blatant bug..but the next thing to try is feeding this string to the convert functions through a "safe" path and see if it hangs.. and address the control-c issue maybe (if it is process kill though, fix is to just run less code..) >> Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") (note that hotmail ruined the pragmas due to the angle brackets..) and I'll have to find what the parameter to m3_dtoawas. Btw, the bug was, quake: if defined("FOO") if equal("FOO", "BAR") something else something else instead of if defined("FOO") if equal(FOO, "BAR") - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure > Date: Fri, 24 Jul 2009 10:06:52 -0400 > > Yeah, I don't think control C works reasonably for all points in GC. > Perhaps just eliminate the signal handler? Not sure. > > > > On 24 Jul 2009, at 06:44, Jay K wrote: > >> >> I'm seeing wierd stuff. >> >> On PPC_LINUX. >> >> Compiling some files hangs. >> Such as M3Front.m3. >> >> It is actually looping forever in >> >> Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") >> >> >> which, you know, other than feeding it bad data, or corrupting >> its stack when it calls out to our lock/unlock, we can't mess up. >> >> >> I can watch what strings it gets on other systems and/or make >> a standalone case that hangs. >> >> >> While investigating this I hit control-c on a cm3 and hit: >> >> >> new source -> compiling SchedulerPosix.i3 (hung here) >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >> *** >> Aborted >> >> >> >> PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = >> BEGIN >> WHILE h < he DO >> >> line 1087 >> >> >> Maybe we don't deal with control-c at arbitrary points?? >> >> >> I was able to reproduce this assertion failure twice in a row.. >> though it moved to line 1089 the second time. >> >> >> >> PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = >> BEGIN >> WHILE h < he DO >> >> >> IF h.gray THEN >> line 1089 >> >> >> I verified that the hang compiling SchedulerPosix.i3 is also related >> to floating point conversion. >> This time in m3_dtoa. >> >> >> I will look further. >> Maybe my config file changes..but seems odd.. >> >> - Jay >> >> >> - Jay >> >> > From hosking at cs.purdue.edu Fri Jul 24 16:14:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 24 Jul 2009 10:14:08 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090724071308.62663CC81C@birch.elegosoft.com> References: <20090724071308.62663CC81C@birch.elegosoft.com> Message-ID: <6309A64A-4FD5-4EF6-B58E-7E791F1E6DF7@cs.purdue.edu> On 24 Jul 2009, at 09:13, Jay Krell wrote: > Log message: > VAX was actually Ultrix apparently, not VMS, so remove VMS entry > until we have an actual VMS port Very amusing! :-) From rcoleburn at scires.com Fri Jul 24 17:47:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 24 Jul 2009 11:47:10 -0400 Subject: [M3devel] Hudson question In-Reply-To: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: <4A699EF1.1E75.00D7.1@scires.com> Olaf: If we switch to Hudson, does that offer any improvement in the Windows arena? We haven't been able to get Tinderbox to work for Windows. I don't mind hosting something for Windows to do the tests if that will help. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 24 18:17:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 18:17:29 +0200 Subject: [M3devel] Hudson question In-Reply-To: <4A699EF1.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> Message-ID: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > If we switch to Hudson, does that offer any improvement in the Windows arena? > > We haven't been able to get Tinderbox to work for Windows. > > I don't mind hosting something for Windows to do the tests if that will help. Well, yes and no ;-) Hudson itself should be as easy to install on Windows as on Unix, as it's completely written in Java. You just download the hudson.war file and start it with java -jar hudson.war. Java should be at least a recent 1.6 distribution. You can just try that and play around with the server if you like. The regression test scripts are all written in Bourne shell syntax, so you'd need Cygwin to run those again. There are probably a few quirks left to make them really work on Windows. Perhaps the Interix POSIX environment Jay has told about may be better suited, but I don't know. In the Hudson setup on birch and luthien I've used parts of the regression scripts for Tinderbox. If we want the test scripts to be the same on all systems, it may still be difficult. On the other hand, we could start with a much simpler setup on Windows. Begin with just one test job that checks out and compiles everything. That should be easy to achieve. I don't know if you can use the cmd scripts in Hudson on Windows, but I assume you can. If that works, we could start with transferring your build results to the Hudson server on birch. Or you could allow birch to control your Hudson installation as a slave server. Does that sound feasible? Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 01:12:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:12:30 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: It doesn't likely make a difference. Before you needed Cygwin or Interix. Now you need Cygwin or Interix, and probably Java. Java will probably be a sticking point on various platforms, but the gains are also very nice where it is available. I see there has been work done on an assembly-free Java VM since Sun open sourced their VM, so that promises increased portability. (One wonders some about the Critical Mass VM). Writing more .cmd isn't going to help anything imho. It's just more hard to maintain code that someone will have to maintain in parallel to Olaf's .sh. Which is why I favor Python -- portable, no duplicated effort. "Hard to main" as it, sure, it is easy to get started, but what happens when you decide you need an array, or a hash table? Or any of a number of basic programming constructs? Ok, I guess you have while loops, using goto. Local variables. At least that are strings. Everything is a string. cmd has one or two surprisingly powerfuli features, such as for /f and set /a. If you can't do your work with them, you can't do it. sh is a bit more portable than Python, but not by much and imho at too large a cost in maintainability/generality. It still seems to me like a string based language that can't do much, but I admit I'm not practised in it. (I am very practised in .cmd.) You know, the fact that expression evaluation is in some mix of the "[" command and maybe in sh itself. That people write if xxx true else yyy instead of if not xxx yyy. The fact that Solaris is different. The fact that quoting is needed in various places. Quoting always bothers me. It is hard to predict how many levels of unquoting will be done. I suspect cmd, sh, and Tcl are all in the same overly string based boat. For example in Tcl, { } appear to have the same meaning as in C and C++, good, but in fact they are escape characters, very wierd and bad. Cygwin and Interix both probably work fine. Someone just has to set them up and run them. Consider Cygwin and Interix almost the same. Interix is much faster, if you are calling fork a lot. Cygwin is slightly more compatible with Linux/Posix. Interix has a few ways in which is resembles Linux/Posix more though, such as not using extensions on executables, using ".so", supporting runpath. I think with Cygwin 1.7, both it and Interix go to extreme of supporting backward slash and colon in paths. Interix actually ors in 0xFF00 to such characters but it is transparent to Interix code. Or maybe that's what Cygwin does. I don't remember. It is completely non transparent and discoverable if you look at the results from Win32. Interix probably a larger download, because the part that is mostly "built in" is basically nothing, just some infrastructure and very few utilities. I don't think there is even sh or ksh. Everything else is one large download. On XP nothing is "builtin", there is just one large download. "builtin" is on Server 2003 R2, Vista, Server 2008, etc. (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 18:17:29 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson question > > Quoting Randy Coleburn : > >> Olaf: >> >> If we switch to Hudson, does that offer any improvement in the Windows arena? >> >> We haven't been able to get Tinderbox to work for Windows. >> >> I don't mind hosting something for Windows to do the tests if that will help. > > Well, yes and no ;-) > > Hudson itself should be as easy to install on Windows as on Unix, > as it's completely written in Java. You just download the hudson.war > file and start it with java -jar hudson.war. Java should be at least > a recent 1.6 distribution. You can just try that and play around with > the server if you like. > > The regression test scripts are all written in Bourne shell syntax, > so you'd need Cygwin to run those again. There are probably a few > quirks left to make them really work on Windows. Perhaps the Interix > POSIX environment Jay has told about may be better suited, but I don't > know. > > In the Hudson setup on birch and luthien I've used parts of the > regression scripts for Tinderbox. If we want the test scripts to be > the same on all systems, it may still be difficult. > > On the other hand, we could start with a much simpler setup on Windows. > Begin with just one test job that checks out and compiles everything. > That should be easy to achieve. I don't know if you can use the cmd > scripts in Hudson on Windows, but I assume you can. If that works, > we could start with transferring your build results to the Hudson > server on birch. Or you could allow birch to control your Hudson > installation as a slave server. > > Does that sound feasible? > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sat Jul 25 01:16:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:16:33 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: [truncated as usual..] ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Hudson question > Date: Fri, 24 Jul 2009 23:12:30 +0000 > > > It doesn't likely make a difference. > > > Before you needed Cygwin or Interix. > Now you need Cygwin or Interix, and probably Java. > Java will probably be a sticking point on various platforms, > but the gains are also very nice where it is available. > I see there has been work done on an assembly-free Java VM > since Sun open sourced their VM, so that promises increased portability. > (One wonders some about the Critical Mass VM). > > > Writing more .cmd isn't going to help anything imho. > It's just more hard to maintain code that someone > will have to maintain in parallel to Olaf's .sh. > Which is why I favor Python -- portable, no duplicated effort. > > > "Hard to main" as it, sure, it is easy to get started, but > what happens when you decide you need an array, or a hash table? > Or any of a number of basic programming constructs? > Ok, I guess you have while loops, using goto. > Local variables. At least that are strings. Everything is a string. > cmd has one or two surprisingly powerfuli features, such as for /f > and set /a. If you can't do your work with them, you can't do it. > sh is a bit more portable than Python, but not by much and > imho at too large a cost in maintainability/generality. > It still seems to me like a string based language that can't do much, > but I admit I'm not practised in it. (I am very practised in .cmd.) > > > You know, the fact that expression evaluation is in some mix of the "[" command > and maybe in sh itself. That people write if xxx true else yyy instead > of if not xxx yyy. > The fact that Solaris is different. > The fact that quoting is needed in various places. > Quoting always bothers me. It is hard to predict how many levels > of unquoting will be done. > I suspect cmd, sh, and Tcl are all in the same overly string based boat. > For example in Tcl, { } appear to have the same meaning as in C and C++, good, > but in fact they are escape characters, very wierd and bad. > > > Cygwin and Interix both probably work fine. > Someone just has to set them up and run them. > > > Consider Cygwin and Interix almost the same. > Interix is much faster, if you are calling fork a lot. > Cygwin is slightly more compatible with Linux/Posix. > > > Interix has a few ways in which is resembles Linux/Posix more though, > such as not using extensions on executables, using ".so", supporting > runpath. > > > I think with Cygwin 1.7, both it and Interix go to extreme > of supporting backward slash and colon in paths. > Interix actually ors in 0xFF00 to such characters but > it is transparent to Interix code. Or maybe that's what > Cygwin does. I don't remember. It is completely non > transparent and discoverable if you look at the results from Win32. > > > Interix probably a larger download, because the > part that is mostly "built in" is basically nothing, > just some infrastructure and very few utilities. > I don't think there is even sh or ksh. > Everything else is one large download. > > > On XP nothing is "builtin", there is just one large download. > "builtin" is on Server 2003 R2, Vista, Server 2008, etc. > > > (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. > But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) > > > - Jay > > > ---------------------------------------- >> Date: Fri, 24 Jul 2009 18:17:29 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Hudson question >> >> Quoting Randy Coleburn : >> >>> Olaf: >>> >>> If we switch to Hudson, does that offer any improvement in the Windows arena? >>> >>> We haven't been able to get Tinderbox to work for Windows. >>> >>> I don't mind hosting something for Windows to do the tests if that will help. >> >> Well, yes and no ;-) >> >> Hudson itself should be as easy to install on Windows as on Unix, >> as it's completely written in Java. You just download the hudson.war >> file and start it with java -jar hudson.war. Java should be at least >> a recent 1.6 distribution. You can just try that and play around with >> the server if you like. >> >> The regression test scripts are all written in Bourne shell syntax, >> so you'd need Cygwin to run those again. There are probably a few >> quirks left to make them really work on Windows. Perhaps the Interix >> POSIX environment Jay has told about may be better suited, but I don't >> know. >> >> In the Hudson setup on birch and luthien I've used parts of the >> regression scripts for Tinderbox. If we want the test scripts to be >> the same on all systems, it may still be difficult. >> >> On the other hand, we could start with a much simpler setup on Windows. >> Begin with just one test job that checks out and compiles everything. >> That should be easy to achieve. I don't know if you can use the cmd >> scripts in Hudson on Windows, but I assume you can. If that works, >> we could start with transferring your build results to the Hudson >> server on birch. Or you could allow birch to control your Hudson >> installation as a slave server. >> >> Does that sound feasible? >> >> Regards, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sat Jul 25 01:18:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:18:17 +0000 Subject: [M3devel] FW: Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: [truncated again, one more try then I give up..] > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] Hudson question >> Date: Fri, 24 Jul 2009 23:12:30 +0000 >> >> >> It doesn't likely make a difference. >> >> >> Before you needed Cygwin or Interix. >> Now you need Cygwin or Interix, and probably Java. >> Java will probably be a sticking point on various platforms, >> but the gains are also very nice where it is available. >> I see there has been work done on an assembly-free Java VM >> since Sun open sourced their VM, so that promises increased portability. >> (One wonders some about the Critical Mass VM). >> >> >> Writing more .cmd isn't going to help anything imho. >> It's just more hard to maintain code that someone >> will have to maintain in parallel to Olaf's .sh. >> Which is why I favor Python -- portable, no duplicated effort. >> >> >> "Hard to main" as it, sure, it is easy to get started, but >> what happens when you decide you need an array, or a hash table? >> Or any of a number of basic programming constructs? >> Ok, I guess you have while loops, using goto. >> Local variables. At least that are strings. Everything is a string. >> cmd has one or two surprisingly powerfuli features, such as for /f >> and set /a. If you can't do your work with them, you can't do it. >> sh is a bit more portable than Python, but not by much and >> imho at too large a cost in maintainability/generality. >> It still seems to me like a string based language that can't do much, >> but I admit I'm not practised in it. (I am very practised in .cmd.) >> >> >> You know, the fact that expression evaluation is in some mix of the "[" command >> and maybe in sh itself. That people write if xxx true else yyy instead >> of if not xxx yyy. >> The fact that Solaris is different. >> The fact that quoting is needed in various places. >> Quoting always bothers me. It is hard to predict how many levels >> of unquoting will be done. >> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >> but in fact they are escape characters, very wierd and bad. >> >> >> Cygwin and Interix both probably work fine. >> Someone just has to set them up and run them. >> >> >> Consider Cygwin and Interix almost the same. >> Interix is much faster, if you are calling fork a lot. >> Cygwin is slightly more compatible with Linux/Posix. >> >> >> Interix has a few ways in which is resembles Linux/Posix more though, >> such as not using extensions on executables, using ".so", supporting >> runpath. >> >> >> I think with Cygwin 1.7, both it and Interix go to extreme >> of supporting backward slash and colon in paths. >> Interix actually ors in 0xFF00 to such characters but >> it is transparent to Interix code. Or maybe that's what >> Cygwin does. I don't remember. It is completely non >> transparent and discoverable if you look at the results from Win32. >> >> >> Interix probably a larger download, because the >> part that is mostly "built in" is basically nothing, >> just some infrastructure and very few utilities. >> I don't think there is even sh or ksh. >> Everything else is one large download. >> >> >> On XP nothing is "builtin", there is just one large download. >> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >> >> >> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >> >> >> - Jay >> >> >> ---------------------------------------- [deliberate snip] From jay.krell at cornell.edu Sat Jul 25 01:30:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:30:23 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: Interix is actually multiple downloads. The first one has a lot of bugs, like gcc never working on systems that support the "no execute" bit, and the NFS server or client crashing the machine (bugcheck, blue screen). To get updates, instead of the usual windowsupdate.microsoft.com, you have to go a special web page, type in the KB articles that you discover searching the web, recieve a link to a password-protected executable/.zip, you get the current password and the next one. If you wait too long, or gosh, want to reinstall everything, officially you need to go through the ridiculuous rigamarole again. Though actually what you can do is extract the .exes/.zips once and keep those around. The first large download from Microsoft gives you a bunch of "utilities", like sh, ksh, gcc, ld, bash. There is also a large second download from interopsystems.com or such to get more and updated utilities. That's where I got e.g. Python. There is a small problem compiling Python out of the box, something around filesystem case sensitivity, even though Interix does offer case sensitive file system, there seems to be a small problem with it. Python detects the case sensitive file system, in which case it is willing to put Python directory and python executable file next to each other, but when it later runs "sh -c ./python", that tries to run the directory and gets access denied. There is a code path in configure for case insensitive, which alters the paths, presumably the workaround is to set the environment variable to force the configure check. Heck, they could just always do it that way.. Presumably starting with a base of Server 2003 R2 or Vista or newer is better, but the above is the experience on XP. So, it is kind of a pain on XP, but the result is way way faster than Cygwin. The cost of fork on Cygwin is huge and definitely occurs. I'm still in the habit of using Cygwin though, like for cvs. Cygwin is multiple downloads in a sense, but they have a fairly nice setup that will do them all. I think the interopsystems.com download does lead pretty directly to X Windows too via a separate package. I just have to remind folks that if the main goal is just forward slashes in file system paths, NT386 works fine there now. Granted, I understand, you also want sh, X windows, 64bit LONGINT, optimizing backend backend (MinGW can deliver the last two). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: FW: [M3devel] Hudson question > Date: Fri, 24 Jul 2009 23:18:17 +0000 > > > [truncated again, one more try then I give up..] > >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>> Subject: RE: [M3devel] Hudson question >>> Date: Fri, 24 Jul 2009 23:12:30 +0000 >>> >>> >>> It doesn't likely make a difference. >>> >>> >>> Before you needed Cygwin or Interix. >>> Now you need Cygwin or Interix, and probably Java. >>> Java will probably be a sticking point on various platforms, >>> but the gains are also very nice where it is available. >>> I see there has been work done on an assembly-free Java VM >>> since Sun open sourced their VM, so that promises increased portability. >>> (One wonders some about the Critical Mass VM). >>> >>> >>> Writing more .cmd isn't going to help anything imho. >>> It's just more hard to maintain code that someone >>> will have to maintain in parallel to Olaf's .sh. >>> Which is why I favor Python -- portable, no duplicated effort. >>> >>> >>> "Hard to main" as it, sure, it is easy to get started, but >>> what happens when you decide you need an array, or a hash table? >>> Or any of a number of basic programming constructs? >>> Ok, I guess you have while loops, using goto. >>> Local variables. At least that are strings. Everything is a string. >>> cmd has one or two surprisingly powerfuli features, such as for /f >>> and set /a. If you can't do your work with them, you can't do it. >>> sh is a bit more portable than Python, but not by much and >>> imho at too large a cost in maintainability/generality. >>> It still seems to me like a string based language that can't do much, >>> but I admit I'm not practised in it. (I am very practised in .cmd.) >>> >>> >>> You know, the fact that expression evaluation is in some mix of the "[" command >>> and maybe in sh itself. That people write if xxx true else yyy instead >>> of if not xxx yyy. >>> The fact that Solaris is different. >>> The fact that quoting is needed in various places. >>> Quoting always bothers me. It is hard to predict how many levels >>> of unquoting will be done. >>> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >>> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >>> but in fact they are escape characters, very wierd and bad. >>> >>> >>> Cygwin and Interix both probably work fine. >>> Someone just has to set them up and run them. >>> >>> >>> Consider Cygwin and Interix almost the same. >>> Interix is much faster, if you are calling fork a lot. >>> Cygwin is slightly more compatible with Linux/Posix. >>> >>> >>> Interix has a few ways in which is resembles Linux/Posix more though, >>> such as not using extensions on executables, using ".so", supporting >>> runpath. >>> >>> >>> I think with Cygwin 1.7, both it and Interix go to extreme >>> of supporting backward slash and colon in paths. >>> Interix actually ors in 0xFF00 to such characters but >>> it is transparent to Interix code. Or maybe that's what >>> Cygwin does. I don't remember. It is completely non >>> transparent and discoverable if you look at the results from Win32. >>> >>> >>> Interix probably a larger download, because the >>> part that is mostly "built in" is basically nothing, >>> just some infrastructure and very few utilities. >>> I don't think there is even sh or ksh. >>> Everything else is one large download. >>> >>> >>> On XP nothing is "builtin", there is just one large download. >>> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >>> >>> >>> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >>> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- > [deliberate snip] > From rcoleburn at scires.com Sat Jul 25 02:43:13 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 24 Jul 2009 20:43:13 -0400 Subject: [M3devel] FW: Hudson question In-Reply-To: References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: <4A6A1C90.1E75.00D7.1@scires.com> Jay: I know you are pro Python and some scripts are in python and some scripts are in .sh and there is cygwin etc etc, but let me list why I think we need CMD on Windows: 1. CMD comes with Windows out-of-the-box. No extra config/install is required. 2. I want to be able to launch a CMD window and use the cm3 command line tools to build Modula-3 packages. I also want to be able to run Modula-3 programs without need of any other tools except what comes with Windows by default. Now the latter isn't exactly possible if you are dependent on the .NET framework, but most systems have .NET anyway because Microsoft has pushed it out through online updates. 3. I continue to experience problems with cygwin, python, etc. because the setup in each is slightly different and there are dependencies that are not obvious. If you succeed in installing cm3 using cygwin, it isn't always possible to build/run packages from CMD. I haven't been able to get the python scripts to work for me, despite installing python. 4. CM3IDE launches the native shell to run the cm3 command line tools. On Windows, this shell is CMD. We need to preserve this functionality. 5. I have provided various CMD scripts in the repository and I've been keeping these up-to-date. I don't mind continuing to do this. 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. 7. Whatever automated test environment we provide on Windows must work in the native shell in order to prove that stuff is working in that shell. If you use cygwin or some other shell, that doesn't mean it will work in CMD. Regards, Randy Coleburn >>> Jay K 7/24/2009 7:18 PM >>> [truncated again, one more try then I give up..] > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] Hudson question >> Date: Fri, 24 Jul 2009 23:12:30 +0000 >> >> >> It doesn't likely make a difference. >> >> >> Before you needed Cygwin or Interix. >> Now you need Cygwin or Interix, and probably Java. >> Java will probably be a sticking point on various platforms, >> but the gains are also very nice where it is available. >> I see there has been work done on an assembly-free Java VM >> since Sun open sourced their VM, so that promises increased portability. >> (One wonders some about the Critical Mass VM). >> >> >> Writing more .cmd isn't going to help anything imho. >> It's just more hard to maintain code that someone >> will have to maintain in parallel to Olaf's .sh. >> Which is why I favor Python -- portable, no duplicated effort. >> >> >> "Hard to main" as it, sure, it is easy to get started, but >> what happens when you decide you need an array, or a hash table? >> Or any of a number of basic programming constructs? >> Ok, I guess you have while loops, using goto. >> Local variables. At least that are strings. Everything is a string. >> cmd has one or two surprisingly powerfuli features, such as for /f >> and set /a. If you can't do your work with them, you can't do it. >> sh is a bit more portable than Python, but not by much and >> imho at too large a cost in maintainability/generality. >> It still seems to me like a string based language that can't do much, >> but I admit I'm not practised in it. (I am very practised in .cmd.) >> >> >> You know, the fact that expression evaluation is in some mix of the "[" command >> and maybe in sh itself. That people write if xxx true else yyy instead >> of if not xxx yyy. >> The fact that Solaris is different. >> The fact that quoting is needed in various places. >> Quoting always bothers me. It is hard to predict how many levels >> of unquoting will be done. >> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >> but in fact they are escape characters, very wierd and bad. >> >> >> Cygwin and Interix both probably work fine. >> Someone just has to set them up and run them. >> >> >> Consider Cygwin and Interix almost the same. >> Interix is much faster, if you are calling fork a lot. >> Cygwin is slightly more compatible with Linux/Posix. >> >> >> Interix has a few ways in which is resembles Linux/Posix more though, >> such as not using extensions on executables, using ".so", supporting >> runpath. >> >> >> I think with Cygwin 1.7, both it and Interix go to extreme >> of supporting backward slash and colon in paths. >> Interix actually ors in 0xFF00 to such characters but >> it is transparent to Interix code. Or maybe that's what >> Cygwin does. I don't remember. It is completely non >> transparent and discoverable if you look at the results from Win32. >> >> >> Interix probably a larger download, because the >> part that is mostly "built in" is basically nothing, >> just some infrastructure and very few utilities. >> I don't think there is even sh or ksh. >> Everything else is one large download. >> >> >> On XP nothing is "builtin", there is just one large download. >> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >> >> >> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >> >> >> - Jay >> >> >> ---------------------------------------- [deliberate snip] CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 25 03:28:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:28:13 +0000 Subject: [M3devel] FW: Hudson question In-Reply-To: <4A6A1C90.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> <4A6A1C90.1E75.00D7.1@scires.com> Message-ID: > 1. CMD comes with Windows out-of-the-box. No extra config/install is required. So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate. > 2. I want to be able to launch a CMD window and use the cm3 command line tools > to build Modula-3 packages. > I also want to be able to run Modula-3 programs without need of > any other tools except what comes with Windows by default. Now the > latter isn't exactly possible if you are dependent on Agreed and not necessarily contradicted. You need CVS to get the current Modula-3 source, but not to use it. Where is the line? > the .NET framework, but most systems have .NET anyway because Microsoft > has pushed it out through online updates. How is the .NET framework relevant? > 3. I continue to experience problems with cygwin, python, etc. because the setup in > each is slightly different and there are dependencies that are not obvious. Let's work on this? What are the errors? I've installed them each many times on many computers with no problem. One problem you might hit is that you might have both Cygwin and native Python. Start out with just one or the other. > If you succeed in installing cm3 using cygwin, it isn't always possible to build/run > packages from CMD. Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH. However the use of sh is separate from the use of the NT386GNU platform. You can launch native NT386 cm3.exe from Cygwin sh. If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency. > I haven't been able to get the python scripts to work for me, despite installing python. Let's work on that? > 4. CM3IDE launches the native shell to run the cm3 command line tools. > On Windows, this shell is CMD. We need to preserve this functionality. There is no need for CM3IDE to launch any shell at all. Why does it? You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used. Just because a console app runs or a console window comes up, does not imply cmd is anywhere. You do need a cmd wrapper if you use, e.g. redirection, on the command line. Things like system() tend to use cmd. And the Modula-3 wrapper libraries might use cmd. But you really don't need any shell at all. I would not advocate any sh or Python wrapping. Adding sh really slow things down. Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection. > 5. I have provided various CMD scripts in the repository and I've been > keeping these up-to-date. I don't mind continuing to do this. And the Tinderbox and Hudson stuff? I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language. I also haven't (and might not) finished dupliating the .sh. I'm not sure. You know, "soon" I should try one or more of: Old Tinderbox/sh stuff on Windows. New Hudson/sh stuff on Windows. Either of above but having rewritten .sh in .cmd or py. Basically the story was, I was on vacation with a Mac. I needed/wanted changes to the .sh but was unwilling to work on .sh. It is cryptic and despite years of slightly trying, I can't seem to get the hang of it. And then I fear that anything I write will only work one OS. I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few. I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed. > 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. I commited working automation to build an .msi. It could use some polish though. The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3. I investigated a number of options for how to build the setup. I had never previously built an .msi, nor it follows, used Wix. I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner. I can detail what I remember of my experiences. IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files. Another .msi builder was and still is promising. NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience. I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running. > 7. Whatever automated test environment we provide on Windows must work in the > native shell in order to prove that stuff is working in that shell. If you use cygwin > or some other shell, that doesn't mean it will work in CMD. That is a fine line. Not necessarily true, but easier to prove true the other way around, granted. If you don't use Cygwin at all, then definitely the stuff works without Cygwin. If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it. But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script). Do the tests work outside Hudson? Outside Tinderbox? Well, it is not too difficult to run them outside either. Do they work outside the .cmd wrappers? Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake? Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening". Modula-3 is obviously general purpose. :) This dichotomy between "scripting" and non-scripting languages has long bugged me. The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate. I understand the guidance -- "pick the right tool for the job". But there is also guidance -- "don't have too many different tools; don't have a different tool for each job". If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving???? Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc... - Jay From jay.krell at cornell.edu Sat Jul 25 03:40:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:40:38 +0000 Subject: [M3devel] which new platforms do people want? Message-ID: Other than finishing ARM_DARWIN, what platforms are people interested in? And will actually use?? I have /many/ to choice from, via both virtual x86/AMD64 machines and available hardware. Some of these are started but didn't get as far yet as having archives uploaded. I386,AMD64_SOLARIS, NETBSD, OPENBSD (all started and mostly easy, will try to finish these up soon) Alpha of anything (VMS, Linux, *BSD, Tru64) AMD64_NT if MinGW is in good enough shape PPC_NETBSD (should be easy) PPC_FREEBSD (slightly hard to setup) Irix 32bit and 64bit AIX 32bit and 64bit HP-UX PA64 and IA64 (PA32 already in good shape) IA64 of anything (VMS, HP-UX, Linux, *BSD; Linux being the one I have up/running) MIPS of anything (Irix, Linux, *BSD (started)) ARM_LINUX PPC64_DARWIN, LINUX MSDOS/DJGPP (appears to have the timer support for user threads) PPC_MACOS, M68K_MACOS Plan9 (unlikely, uses old gcc fork, best handled with a C backend) Beos (unlikely, not very VM-compatible) DragonflyBSD (VM) WinCE (unlikely, no hardware) ? A C backend could serve pretty much anything. We could likely have C_WIN32 and C_POSIX and nearly all porting work declared done, just two distribution archives, if that. Of course then the "fun" of installing all these systems would be lost. :) I think I can knock off I386,AMD64_SOLARIS, NetBSD, OpenBSD, then try out more esoteric stuff like Alpha and MIPS and then IA64. My $50 network router runs Linux 2.4 on 32bit MIPS, I think with uclibc. It is low end for sure, but has SMB client builtin, so infinite diskspace. I have a network attached hard drive running Linux 2.6 on ARM, with uclibc. uclibc imho threatens our naming conventions, unless we target the Linux kernel instead of libc, which I think is maybe a good idea. Linux 2.4 also treatens the naming convention perhaps. I thought it was long gone but it isn't. Current "distributions" for network routers use it. Maybe there should be MIPS_LINUX_USERTHREADS? Maybe *_USERTHREADS in general, where it works and people will use it? - Jay From jay.krell at cornell.edu Sat Jul 25 03:42:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:42:04 +0000 Subject: [M3devel] FW: FW: Hudson question In-Reply-To: <4A6A1C90.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> <4A6A1C90.1E75.00D7.1@scires.com> Message-ID: [truncated again] ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Hudson question > Date: Sat, 25 Jul 2009 01:28:13 +0000 > > >> 1. CMD comes with Windows out-of-the-box. No extra config/install is required. > > > So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate. > > >> 2. I want to be able to launch a CMD window and use the cm3 command line tools >> to build Modula-3 packages. >> I also want to be able to run Modula-3 programs without need of >> any other tools except what comes with Windows by default. Now the >> latter isn't exactly possible if you are dependent on > > > Agreed and not necessarily contradicted. > You need CVS to get the current Modula-3 source, but not to use it. > Where is the line? > > >> the .NET framework, but most systems have .NET anyway because Microsoft >> has pushed it out through online updates. > > How is the .NET framework relevant? > > >> 3. I continue to experience problems with cygwin, python, etc. because the setup in >> each is slightly different and there are dependencies that are not obvious. > > > Let's work on this? What are the errors? I've installed them each many times on many computers with no problem. > One problem you might hit is that you might have both Cygwin and native Python. > Start out with just one or the other. > > >> If you succeed in installing cm3 using cygwin, it isn't always possible to build/run >> packages from CMD. > > > Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH. > > > However the use of sh is separate from the use of the NT386GNU platform. > You can launch native NT386 cm3.exe from Cygwin sh. > If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency. > > >> I haven't been able to get the python scripts to work for me, despite installing python. > > > Let's work on that? > > >> 4. CM3IDE launches the native shell to run the cm3 command line tools. >> On Windows, this shell is CMD. We need to preserve this functionality. > > There is no need for CM3IDE to launch any shell at all. > Why does it? > You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used. > Just because a console app runs or a console window comes up, does not imply cmd is anywhere. > You do need a cmd wrapper if you use, e.g. redirection, on the command line. > Things like system() tend to use cmd. > And the Modula-3 wrapper libraries might use cmd. > But you really don't need any shell at all. > > > I would not advocate any sh or Python wrapping. Adding sh really slow things down. > > > Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection. > > >> 5. I have provided various CMD scripts in the repository and I've been >> keeping these up-to-date. I don't mind continuing to do this. > > And the Tinderbox and Hudson stuff? > I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language. > I also haven't (and might not) finished dupliating the .sh. > I'm not sure. > You know, "soon" I should try one or more of: > Old Tinderbox/sh stuff on Windows. > New Hudson/sh stuff on Windows. > Either of above but having rewritten .sh in .cmd or py. > > > Basically the story was, I was on vacation with a Mac. > I needed/wanted changes to the .sh but was unwilling to work on .sh. > It is cryptic and despite years of slightly trying, I can't seem to get the hang of it. > And then I fear that anything I write will only work one OS. > I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few. > > I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed. > > >> 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. > > > I commited working automation to build an .msi. > It could use some polish though. > The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3. > > > I investigated a number of options for how to build the setup. > I had never previously built an .msi, nor it follows, used Wix. > I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner. > I can detail what I remember of my experiences. > IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files. > Another .msi builder was and still is promising. > NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience. > > > I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running. > > >> 7. Whatever automated test environment we provide on Windows must work in the >> native shell in order to prove that stuff is working in that shell. If you use cygwin >> or some other shell, that doesn't mean it will work in CMD. > > > That is a fine line. > Not necessarily true, but easier to prove true the other way around, granted. > If you don't use Cygwin at all, then definitely the stuff works without Cygwin. > If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it. > > But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script). > > Do the tests work outside Hudson? Outside Tinderbox? > Well, it is not too difficult to run them outside either. > Do they work outside the .cmd wrappers? > > Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake? > Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening". > > > Modula-3 is obviously general purpose. :) > > > This dichotomy between "scripting" and non-scripting languages has long bugged me. > The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate. > > I understand the guidance -- "pick the right tool for the job". > But there is also guidance -- "don't have too many different tools; don't have a different tool for each job". > > If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving???? > Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc... > > > - Jay > From jay.krell at cornell.edu Sat Jul 25 04:06:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 02:06:14 +0000 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: It seems the Tinderbox stuff always keeps around ~/work/cm3-ws/datetime, one for each run? I see them accumulating on my machines. Can you send me/all your exact cron entries? For Tinderbox and Hudson? Even what file they are in? And how cron is enabled in /etc? Just in case? Thanks. - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 11:44:38 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: Hudson errors out of diskspace > > Quoting Jay K : > >> Here's another: >> >> new source -> compiling ../FreeBSD4/cm3unix.c >> ../FreeBSD4/cm3unix.c:3: fatal error: error writing to >> /var/tmp/ccVwJXWF.s: No space left on device > > That was on my home machine because core dumps from m3tests were > accumulating in /var/tmp. I've now set the core dump limit to 0 > for those jobs. > >> Hudson is looking like a big improvement though -- the last success, >> last failure columns, the list of changes in a build, the quick >> access to the full output. > > Yes. I've been using it for about half a year now, and apart from the > fact that it's resource hungry and sometimes slow, it's easy to use > and configure. And you find a plug-in for almost everything. > > Since yesterday afternoon all necessary plug-ins for interaction > with other servers should be installed. > > I've just moved the crontab jobs from user m3 on birch to hudson, > see http://hudson.modula3.com:8080/view/m3-www-support/. > > My network connection is very unstable currently, so more failures > are to be expected. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Sat Jul 25 13:54:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 13:54:36 +0200 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: <20090725135436.4frp8e0c8w8ckgg4@mail.elegosoft.com> Quoting Jay K : > It seems the Tinderbox stuff always keeps around > ~/work/cm3-ws/datetime, one for each run? > I see them accumulating on my machines. Use cleanup_all from scripts/regression/defs.sh. > Can you send me/all your exact cron entries? > For Tinderbox and Hudson? Hudson doesn't have any crontab. It implements cron functionality itself. > Even what file they are in? I don't know where personal crontab files are kept (probably implementation dependent). You just use the crontab command to access them. > And how cron is enabled in /etc? Just in case? I don't think there is any system-independent way to enable cron. Just run the daemon from one of the system startup scripts (/etc/rc or /etc/rc.d/*). > Thanks. Here's the crontab of m3 on birch. Everything is disabled now (moved to Hudson). I'll add some remarks with -->. m3 at birch:~$ crontab -l MAILTO=m3-support at elego.de TESTHOSTNAME=birch.elegosoft.com ### Note: all these crontab jobs have been moved to the CM3 hudson instance on birch # m h dom mon dow command --> crontabs residing in /etc will likely have another field for the user: --> # m h dom mon dow user command #0 2,14 * * * cd ~/cm3 && BUILD_REL=lastok ./tinderbox-build.sh cm3.build >/dev/null #0 4,16 * * * cd ~/cm3 && ./tinderbox-build.sh cm3.build >/dev/null --> These were the release-build and last-ok build when LINUXLIBC6 was --> the target on birch #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_pkg_status.sh #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_m3tests.sh #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_snapshot_status.sh #*/30 * * * * ${HOME}/bin/update_changelog.sh #*/30 * * * * cd /var/www/modula3.elegosoft.com/cm3/uploaded-archives && ./update_download_index.sh #5 7 * * * cd /var/www/modula3.elegosoft.com/cm3/ && make all >/dev/null --> old WWW service entries before the crash # This should work ### 0 14 * * * cd ~/cm3 && BUILD_REL=lastok ./tinderbox-build.sh cm3.build >/dev/null 2>&1 --> This was run till yesterday, but with additional tests in cm3.build # Cannot work, no release archives for AMD64_LINUX #0 4,16 * * * cd ~/cm3 && ./tinderbox-build.sh cm3.build >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_pkg_status.sh >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_m3tests.sh >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_snapshot_status.sh >/dev/null 2>&1 ### */60 * * * * ${HOME}/bin/update_changelog.sh >/dev/null 2>&1 ### */30 * * * * cd /var/www/modula3.elegosoft.com/cm3/uploaded-archives && ./update_download_index.sh >/dev/null 2>&1 ### 5 7 * * * cd /var/www/modula3.elegosoft.com/cm3/ && make all >/dev/null >/dev/null 2>&1 --> entries inserted after the crash, when nothing was working correctly... Does that help? If you can run Hudson on any of your systems, I wouldn't bother with cron. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 16:58:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 09:58:24 -0500 Subject: [M3devel] Fwd: Output from "cron" command References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> Message-ID: <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> This is an old error for Solaris that I fixed a long time ago. Can someone restore? Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: July 25, 2009 5:30:35 AM CDT > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > U regression-scripts/defs.sh > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.07.25 06:30:23 -- checkout in progress. > [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is not > of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set > incorrectly, or the mail was delayed for a long time. > variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.07.25 06:30:32 -- checkout in progress. > [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is not > of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set > incorrectly, or the mail was delayed for a long time. > variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 20:00:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:00:26 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> Message-ID: <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> Quoting Tony Hosking : > This is an old error for Solaris that I fixed a long time ago. Can > someone restore? Hi Tony, as far as I can see nothing has changed regarding STARTTIME: > % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME|date' Annotations for scripts/regression/tinderbox-build.sh *************** 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date '+%Y%m%d-%H%M%S'`" 1.8 (wagner 03-Feb-08): STARTTIME="$4" 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z "${BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] 1.8 (wagner 03-Feb-08): echo " date 'date +%s'" 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date +%s` 1.8 (wagner 03-Feb-08): tinderbox_header "${TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." 1.10 (hosking 09-Mar-08): echo "[start checkout `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end checkout `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- compile in progress." 1.10 (hosking 09-Mar-08): echo "[start compile `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- tests in progress." 1.10 (hosking 09-Mar-08): echo "[start run-tests `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end run-tests `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." Nothing at all has changed in these scripts in July: % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 Annotations for scripts/regression/tinderbox-build.sh *************** luthien [~/work/cm3] wagner % cvs ann scripts/regression/cm3.bu | egrep Jul-09 cm3.build cm3.build~ luthien [~/work/cm3] wagner % cvs ann scripts/regression/cm3.build | egrep Jul-09 Annotations for scripts/regression/cm3.build *************** luthien [~/work/cm3] wagner Perhaps I'm looking for the wrong thing. What exactly did you change long ago to make it work? I'm at a loss now. > Sent from my iPhone You seem to be very `mobile' lately ;-) > Begin forwarded message: > >> From: Tony Hosking >> Date: July 25, 2009 5:30:35 AM CDT >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> > >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> U regression-scripts/defs.sh >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.07.25 06:30:23 -- checkout in progress. >> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is not >> of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set >> incorrectly, or the mail was delayed for a long time. >> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >> >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.07.25 06:30:32 -- checkout in progress. >> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is not >> of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set >> incorrectly, or the mail was delayed for a long time. >> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >> >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 25 20:10:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:10:52 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc Message-ID: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> We've got two failures for package tests on birch that don't show up on FreeBSD: http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ I think Jay already mentioned that there might be a conflict. Any objections to rename the m3 library? I think I'll just try it and see what happens... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 20:12:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 18:12:19 +0000 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: I thought I already renamed it but maybe I messed up or maybe the report is old? - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 20:10:52 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] package test failures on birch: duplicate libodbc > > We've got two failures for package tests on birch that don't show up > on FreeBSD: > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ > > I think Jay already mentioned that there might be a conflict. > > Any objections to rename the m3 library? > > I think I'll just try it and see what happens... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Sat Jul 25 20:16:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:16:55 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: <20090725201655.030d1ygif4cgksg4@mail.elegosoft.com> Quoting Jay K : > I thought I already renamed it but maybe I messed up or maybe the > report is old? I just found out you had, too. The report is not old. Perhaps we need to remove old libs manually which are still left in /usr/local/cm3/lib? I'll try that... Olaf > > - Jay > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:10:52 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] package test failures on birch: duplicate libodbc >> >> We've got two failures for package tests on birch that don't show up >> on FreeBSD: >> >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >> >> I think Jay already mentioned that there might be a conflict. >> >> Any objections to rename the m3 library? >> >> I think I'll just try it and see what happens... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 20:15:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 18:15:14 +0000 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: Hm, maybe the problem is that shipping should delete the old files? Should I add something called, like install_delete_file? delete_installed_file?? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 25 Jul 2009 18:12:19 +0000 > Subject: Re: [M3devel] package test failures on birch: duplicate libodbc > > > I thought I already renamed it but maybe I messed up or maybe the report is old? > > - Jay > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:10:52 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] package test failures on birch: duplicate libodbc >> >> We've got two failures for package tests on birch that don't show up >> on FreeBSD: >> >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >> >> I think Jay already mentioned that there might be a conflict. >> >> Any objections to rename the m3 library? >> >> I think I'll just try it and see what happens... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sat Jul 25 20:27:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:27:10 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: <20090725202710.xq62yw55c848o8g4@mail.elegosoft.com> Quoting Jay K : > Hm, maybe the problem is that shipping should delete the old files? > > Should I add something called, like install_delete_file? > delete_installed_file?? No, this is a migration problem that cannot be solved by the build tooling without being aware of all the history. I just removed all cm3 libodbc.so files on birch (except those in your home). If the tests succeed now, we can forget about it. Olaf > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Date: Sat, 25 Jul 2009 18:12:19 +0000 >> Subject: Re: [M3devel] package test failures on birch: duplicate libodbc >> >> >> I thought I already renamed it but maybe I messed up or maybe the >> report is old? >> >> - Jay >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:10:52 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] package test failures on birch: duplicate libodbc >>> >>> We've got two failures for package tests on birch that don't show up >>> on FreeBSD: >>> >>> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >>> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >>> >>> I think Jay already mentioned that there might be a conflict. >>> >>> Any objections to rename the m3 library? >>> >>> I think I'll just try it and see what happens... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 20:32:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 14:32:08 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> Message-ID: <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> Perhaps I am confusing with the original change I made for 1.10 to the parameter to the "date" command. In any case, something changed so that my scripts did not run properly. It's been a long time since I've seen a sane tinderbox run for Solaris -- will things be stabilising soon? -- Tony (not mobile) On 25 Jul 2009, at 14:00, Olaf Wagner wrote: > Quoting Tony Hosking : > >> This is an old error for Solaris that I fixed a long time ago. Can >> someone restore? > > Hi Tony, > > as far as I can see nothing has changed regarding STARTTIME: > > >> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| >> date' > > Annotations for scripts/regression/tinderbox-build.sh > *************** > 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date '+%Y > %m%d-%H%M%S'`" > 1.8 (wagner 03-Feb-08): STARTTIME="$4" > 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z "$ > {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] > 1.8 (wagner 03-Feb-08): echo > " date 'date +%s'" > 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: > $STARTTIME > 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + > %s` > 1.8 (wagner 03-Feb-08): tinderbox_header "$ > {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" > 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- checkout in progress." > 1.10 (hosking 09-Mar-08): echo "[start checkout `date '+ > %Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end checkout `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- compile in progress." > 1.10 (hosking 09-Mar-08): echo "[start compile `date '+ > %Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- tests in progress." > 1.10 (hosking 09-Mar-08): echo "[start run-tests `date > '+%Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end run-tests `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- checkout, compile and test run done." > > Nothing at all has changed in these scripts in July: > > % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 > > Annotations for scripts/regression/tinderbox-build.sh > *************** > luthien [~/work/cm3] wagner > % cvs ann scripts/regression/cm3.bu | egrep Jul-09 > cm3.build cm3.build~ > luthien [~/work/cm3] wagner > % cvs ann scripts/regression/cm3.build | egrep Jul-09 > > Annotations for scripts/regression/cm3.build > *************** > luthien [~/work/cm3] wagner > > > Perhaps I'm looking for the wrong thing. What exactly did you change > long ago to make it work? I'm at a loss now. > >> Sent from my iPhone > > You seem to be very `mobile' lately ;-) > > >> Begin forwarded message: >> >>> From: Tony Hosking >>> Date: July 25, 2009 5:30:35 AM CDT >>> To: hosking at cs.purdue.edu >>> Subject: Output from "cron" command >>> >> >>> Your "cron" job on niagara.cs.purdue.edu >>> $HOME/cm3/scripts/regression/cron.sh >>> >>> produced the following output: >>> >>> U regression-scripts/defs.sh >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>> >>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.07.25 06:30:23 -- checkout in progress. >>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>> is set incorrectly, or the mail was delayed for a long time. >>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>> >>> Error: Sending buildlog failed! >>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>> >>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.07.25 06:30:32 -- checkout in progress. >>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>> is set incorrectly, or the mail was delayed for a long time. >>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>> minutes) >>> >>> Error: Sending buildlog failed! >>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 20:44:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:44:38 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> Message-ID: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Quoting Tony Hosking : > Perhaps I am confusing with the original change I made for 1.10 to the > parameter to the "date" command. > > In any case, something changed so that my scripts did not run > properly. It's been a long time since I've seen a sane tinderbox run > for Solaris -- will things be stabilising soon? I broke the last one yesterday with $() (fixed soon afterwards), but the one before succeeded: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 I was hoping to get a green build from one of your systems today (big-endian, different architecture) to finally fix the RC2 tag. But if you cannot send your results to the tinderbox that will be difficult :-/ I really don't understand why that should have stopped working. The error below seems to be that the reported start time is 0, and that cannot be according to the source. Could you set -x at the start of the tinderbox script and try again? Jay, can you think of anything you have changed that may cause Tony's problem? Olaf > -- Tony (not mobile) :-) > On 25 Jul 2009, at 14:00, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> This is an old error for Solaris that I fixed a long time ago. Can >>> someone restore? >> >> Hi Tony, >> >> as far as I can see nothing has changed regarding STARTTIME: >> >> >>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >> >> Annotations for scripts/regression/tinderbox-build.sh >> *************** >> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >> '+%Y %m%d-%H%M%S'`" >> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >> 1.8 (wagner 03-Feb-08): echo " >> date 'date +%s'" >> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >> %S'` -- checkout in progress." >> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >> '+ %Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >> '+%Y. %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >> %H:%M: %S'` -- compile in progress." >> 1.10 (hosking 09-Mar-08): echo "[start compile `date >> '+ %Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >> %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >> %H:%M: %S'` -- tests in progress." >> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >> '+%Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >> '+%Y. %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >> %S'` -- checkout, compile and test run done." >> >> Nothing at all has changed in these scripts in July: >> >> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >> >> Annotations for scripts/regression/tinderbox-build.sh >> *************** >> luthien [~/work/cm3] wagner >> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >> cm3.build cm3.build~ >> luthien [~/work/cm3] wagner >> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >> >> Annotations for scripts/regression/cm3.build >> *************** >> luthien [~/work/cm3] wagner >> >> >> Perhaps I'm looking for the wrong thing. What exactly did you change >> long ago to make it work? I'm at a loss now. >> >>> Sent from my iPhone >> >> You seem to be very `mobile' lately ;-) >> >> >>> Begin forwarded message: >>> >>>> From: Tony Hosking >>>> Date: July 25, 2009 5:30:35 AM CDT >>>> To: hosking at cs.purdue.edu >>>> Subject: Output from "cron" command >>>> >>> >>>> Your "cron" job on niagara.cs.purdue.edu >>>> $HOME/cm3/scripts/regression/cron.sh >>>> >>>> produced the following output: >>>> >>>> U regression-scripts/defs.sh >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>> >>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.07.25 06:30:23 -- checkout in progress. >>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>> is set incorrectly, or the mail was delayed for a long time. >>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>> >>>> Error: Sending buildlog failed! >>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>> >>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.07.25 06:30:32 -- checkout in progress. >>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>> is set incorrectly, or the mail was delayed for a long time. >>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>> >>>> Error: Sending buildlog failed! >>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 21:19:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:19:11 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: This line: echo tinderbox: timenow: `date +%s` needs to more like these lines: echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' 2009.07.25 12:13:54 -bash-3.00$ date '+%m.%d.%y %H:%M:%S' 07.25.09 12:14:33 -bash-3.00$ date +%s %s - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 20:44:38 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Quoting Tony Hosking : > >> Perhaps I am confusing with the original change I made for 1.10 to the >> parameter to the "date" command. >> >> In any case, something changed so that my scripts did not run >> properly. It's been a long time since I've seen a sane tinderbox run >> for Solaris -- will things be stabilising soon? > > I broke the last one yesterday with $() (fixed soon afterwards), but > the one before succeeded: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 > > I was hoping to get a green build from one of your systems today > (big-endian, different architecture) to finally fix the RC2 tag. > But if you cannot send your results to the tinderbox that will be > difficult :-/ I really don't understand why that should have stopped > working. > > The error below seems to be that the reported start time is 0, and > that cannot be according to the source. Could you set -x at the start > of the tinderbox script and try again? > > Jay, can you think of anything you have changed that may cause Tony's > problem? > > Olaf > >> -- Tony (not mobile) > :-) > >> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> This is an old error for Solaris that I fixed a long time ago. Can >>>> someone restore? >>> >>> Hi Tony, >>> >>> as far as I can see nothing has changed regarding STARTTIME: >>> >>> >>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>> >>> Annotations for scripts/regression/tinderbox-build.sh >>> *************** >>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>> '+%Y %m%d-%H%M%S'`" >>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>> 1.8 (wagner 03-Feb-08): echo " >>> date 'date +%s'" >>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>> %S'` -- checkout in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>> '+ %Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>> '+%Y. %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>> %H:%M: %S'` -- compile in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>> '+ %Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>> %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>> %H:%M: %S'` -- tests in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>> '+%Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>> '+%Y. %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>> %S'` -- checkout, compile and test run done." >>> >>> Nothing at all has changed in these scripts in July: >>> >>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>> >>> Annotations for scripts/regression/tinderbox-build.sh >>> *************** >>> luthien [~/work/cm3] wagner >>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>> cm3.build cm3.build~ >>> luthien [~/work/cm3] wagner >>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>> >>> Annotations for scripts/regression/cm3.build >>> *************** >>> luthien [~/work/cm3] wagner >>> >>> >>> Perhaps I'm looking for the wrong thing. What exactly did you change >>> long ago to make it work? I'm at a loss now. >>> >>>> Sent from my iPhone >>> >>> You seem to be very `mobile' lately ;-) >>> >>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> U regression-scripts/defs.sh >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>> is set incorrectly, or the mail was delayed for a long time. >>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>> >>>>> Error: Sending buildlog failed! >>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>> is set incorrectly, or the mail was delayed for a long time. >>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>> >>>>> Error: Sending buildlog failed! >>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sat Jul 25 21:19:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:19:57 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: (two occurences of that) ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Fwd: Output from "cron" command > Date: Sat, 25 Jul 2009 19:19:11 +0000 > > > This line: > > > echo tinderbox: timenow: `date +%s` > > needs to more like these lines: > > echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." > > echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." > > > -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' > 2009.07.25 12:13:54 > > -bash-3.00$ date '+%m.%d.%y %H:%M:%S' > 07.25.09 12:14:33 > > -bash-3.00$ date +%s > %s > > - Jay > > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:44:38 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Quoting Tony Hosking : >> >>> Perhaps I am confusing with the original change I made for 1.10 to the >>> parameter to the "date" command. >>> >>> In any case, something changed so that my scripts did not run >>> properly. It's been a long time since I've seen a sane tinderbox run >>> for Solaris -- will things be stabilising soon? >> >> I broke the last one yesterday with $() (fixed soon afterwards), but >> the one before succeeded: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >> >> I was hoping to get a green build from one of your systems today >> (big-endian, different architecture) to finally fix the RC2 tag. >> But if you cannot send your results to the tinderbox that will be >> difficult :-/ I really don't understand why that should have stopped >> working. >> >> The error below seems to be that the reported start time is 0, and >> that cannot be according to the source. Could you set -x at the start >> of the tinderbox script and try again? >> >> Jay, can you think of anything you have changed that may cause Tony's >> problem? >> >> Olaf >> >>> -- Tony (not mobile) >> :-) >> >>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>> >>>> Quoting Tony Hosking : >>>> >>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>> someone restore? >>>> >>>> Hi Tony, >>>> >>>> as far as I can see nothing has changed regarding STARTTIME: >>>> >>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>>> >>>> Annotations for scripts/regression/tinderbox-build.sh >>>> *************** >>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>> '+%Y %m%d-%H%M%S'`" >>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>> 1.8 (wagner 03-Feb-08): echo " >>>> date 'date +%s'" >>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>> %S'` -- checkout in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>> '+%Y. %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>> %H:%M: %S'` -- compile in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>> %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>> %H:%M: %S'` -- tests in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>> '+%Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>> '+%Y. %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>> %S'` -- checkout, compile and test run done." >>>> >>>> Nothing at all has changed in these scripts in July: >>>> >>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>> >>>> Annotations for scripts/regression/tinderbox-build.sh >>>> *************** >>>> luthien [~/work/cm3] wagner >>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>> cm3.build cm3.build~ >>>> luthien [~/work/cm3] wagner >>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>> >>>> Annotations for scripts/regression/cm3.build >>>> *************** >>>> luthien [~/work/cm3] wagner >>>> >>>> >>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>> long ago to make it work? I'm at a loss now. >>>> >>>>> Sent from my iPhone >>>> >>>> You seem to be very `mobile' lately ;-) >>>> >>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Tony Hosking >>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>> To: hosking at cs.purdue.edu >>>>>> Subject: Output from "cron" command >>>>>> >>>>> >>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>> >>>>>> produced the following output: >>>>>> >>>>>> U regression-scripts/defs.sh >>>>>> TESTHOSTNAME=niagara >>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>> LASTREL=5.4.0 >>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>> CM3_OSTYPE=POSIX >>>>>> CM3_TARGET=SOLgnu >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSUSER= >>>>>> testing ssh birch.elegosoft.com.. >>>>>> ssh birch.elegosoft.com ok >>>>>> Building cm3. >>>>>> Tinderbox Tree: "cm3" >>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>> >>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>> >>>>>> --- >>>>>> >>>>>> checkout, compile and test of cm3 ... >>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>> >>>>>> Error: Sending buildlog failed! >>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>> cleaning CM3 workspaces... >>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>> >>>>>> cleaning regression test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>> >>>>>> cleaning m3test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>> >>>>>> cleaning snapshot files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>> >>>>>> cleaning package reports... >>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>> >>>>>> TESTHOSTNAME=niagara >>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>> LASTREL=5.4.0 >>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>> CM3_OSTYPE=POSIX >>>>>> CM3_TARGET=SOLgnu >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSUSER= >>>>>> testing ssh birch.elegosoft.com.. >>>>>> ssh birch.elegosoft.com ok >>>>>> Building cm3. >>>>>> Tinderbox Tree: "cm3" >>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>> >>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>> >>>>>> --- >>>>>> >>>>>> checkout, compile and test of cm3 ... >>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>> >>>>>> Error: Sending buildlog failed! >>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>> cleaning CM3 workspaces... >>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>> >>>>>> cleaning regression test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>> >>>>>> cleaning m3test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>> >>>>>> cleaning snapshot files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>> >>>>>> cleaning package reports... >>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sat Jul 25 21:26:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:26:37 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: Can I suggest the portable scripting language C? -bash-3.00$ cat date.c #include #include #include int main() { printf("%lu\n", (unsigned long)time(NULL)); return 0; } -bash-3.00$ cc date.c -o ./mydate -bash-3.00$ ./mydate 1248549753 -bash-3.00$ pwd /dev2/cm3/scripts use that instead? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > Date: Sat, 25 Jul 2009 19:19:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > > (two occurences of that) > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sat, 25 Jul 2009 19:19:11 +0000 >> >> >> This line: >> >> >> echo tinderbox: timenow: `date +%s` >> >> needs to more like these lines: >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." >> >> >> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >> 2009.07.25 12:13:54 >> >> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >> 07.25.09 12:14:33 >> >> -bash-3.00$ date +%s >> %s >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>> parameter to the "date" command. >>>> >>>> In any case, something changed so that my scripts did not run >>>> properly. It's been a long time since I've seen a sane tinderbox run >>>> for Solaris -- will things be stabilising soon? >>> >>> I broke the last one yesterday with $() (fixed soon afterwards), but >>> the one before succeeded: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>> >>> I was hoping to get a green build from one of your systems today >>> (big-endian, different architecture) to finally fix the RC2 tag. >>> But if you cannot send your results to the tinderbox that will be >>> difficult :-/ I really don't understand why that should have stopped >>> working. >>> >>> The error below seems to be that the reported start time is 0, and >>> that cannot be according to the source. Could you set -x at the start >>> of the tinderbox script and try again? >>> >>> Jay, can you think of anything you have changed that may cause Tony's >>> problem? >>> >>> Olaf >>> >>>> -- Tony (not mobile) >>> :-) >>> >>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>> someone restore? >>>>> >>>>> Hi Tony, >>>>> >>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>> >>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>> '+%Y %m%d-%H%M%S'`" >>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>> 1.8 (wagner 03-Feb-08): echo " >>>>> date 'date +%s'" >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- compile in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>> %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- tests in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout, compile and test run done." >>>>> >>>>> Nothing at all has changed in these scripts in July: >>>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>> cm3.build cm3.build~ >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/cm3.build >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> >>>>> >>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>> long ago to make it work? I'm at a loss now. >>>>> >>>>>> Sent from my iPhone >>>>> >>>>> You seem to be very `mobile' lately ;-) >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Tony Hosking >>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Subject: Output from "cron" command >>>>>>> >>>>>> >>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>> >>>>>>> produced the following output: >>>>>>> >>>>>>> U regression-scripts/defs.sh >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From wagner at elegosoft.com Sat Jul 25 21:52:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 21:52:13 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> I don't see how that will help us... It worked for Tony for over a year, and nothing obvious has changed. Or did something change on your side, Tony (system upgrade, path setting, ...)? It's not good to introduce arbitrary changes now without understanding why it breaks. Olaf Quoting Jay K : > > Can I suggest the portable scripting language C? > > > -bash-3.00$ cat date.c > #include > #include > #include > int main() > { > printf("%lu\n", (unsigned long)time(NULL)); > return 0; > } > -bash-3.00$ cc date.c -o ./mydate > -bash-3.00$ ./mydate > 1248549753 > -bash-3.00$ pwd > /dev2/cm3/scripts > > > use that instead? > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> Date: Sat, 25 Jul 2009 19:19:57 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> >> (two occurences of that) >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>> >>> >>> This line: >>> >>> >>> echo tinderbox: timenow: `date +%s` >>> >>> needs to more like these lines: >>> >>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>> >>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." >>> >>> >>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>> 2009.07.25 12:13:54 >>> >>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>> 07.25.09 12:14:33 >>> >>> -bash-3.00$ date +%s >>> %s >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>> From: wagner at elegosoft.com >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> Quoting Tony Hosking : >>>> >>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>> parameter to the "date" command. >>>>> >>>>> In any case, something changed so that my scripts did not run >>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>> for Solaris -- will things be stabilising soon? >>>> >>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>> the one before succeeded: >>>> >>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>> >>>> I was hoping to get a green build from one of your systems today >>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>> But if you cannot send your results to the tinderbox that will be >>>> difficult :-/ I really don't understand why that should have stopped >>>> working. >>>> >>>> The error below seems to be that the reported start time is 0, and >>>> that cannot be according to the source. Could you set -x at the start >>>> of the tinderbox script and try again? >>>> >>>> Jay, can you think of anything you have changed that may cause Tony's >>>> problem? >>>> >>>> Olaf >>>> >>>>> -- Tony (not mobile) >>>> :-) >>>> >>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>> >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>> someone restore? >>>>>> >>>>>> Hi Tony, >>>>>> >>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>> >>>>>> >>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>> 'STARTTIME| date' >>>>>> >>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>> *************** >>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>> '+%Y %m%d-%H%M%S'`" >>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>> date 'date +%s'" >>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>> %S'` -- checkout in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>> %H:%M: %S'` -- compile in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>> %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>> %H:%M: %S'` -- tests in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>> %S'` -- checkout, compile and test run done." >>>>>> >>>>>> Nothing at all has changed in these scripts in July: >>>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>> >>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>> *************** >>>>>> luthien [~/work/cm3] wagner >>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>> cm3.build cm3.build~ >>>>>> luthien [~/work/cm3] wagner >>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>> >>>>>> Annotations for scripts/regression/cm3.build >>>>>> *************** >>>>>> luthien [~/work/cm3] wagner >>>>>> >>>>>> >>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>> long ago to make it work? I'm at a loss now. >>>>>> >>>>>>> Sent from my iPhone >>>>>> >>>>>> You seem to be very `mobile' lately ;-) >>>>>> >>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: Tony Hosking >>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Subject: Output from "cron" command >>>>>>>> >>>>>>> >>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>> >>>>>>>> produced the following output: >>>>>>>> >>>>>>>> U regression-scripts/defs.sh >>>>>>>> TESTHOSTNAME=niagara >>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>> LASTREL=5.4.0 >>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>> CM3_OSTYPE=POSIX >>>>>>>> CM3_TARGET=SOLgnu >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSUSER= >>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>> ssh birch.elegosoft.com ok >>>>>>>> Building cm3. >>>>>>>> Tinderbox Tree: "cm3" >>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>> >>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> checkout, compile and test of cm3 ... >>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>> >>>>>>>> Error: Sending buildlog failed! >>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>> cleaning CM3 workspaces... >>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>> >>>>>>>> cleaning regression test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>> >>>>>>>> cleaning m3test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>> >>>>>>>> cleaning snapshot files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>> >>>>>>>> cleaning package reports... >>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>> >>>>>>>> TESTHOSTNAME=niagara >>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>> LASTREL=5.4.0 >>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>> CM3_OSTYPE=POSIX >>>>>>>> CM3_TARGET=SOLgnu >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSUSER= >>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>> ssh birch.elegosoft.com ok >>>>>>>> Building cm3. >>>>>>>> Tinderbox Tree: "cm3" >>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>> >>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> checkout, compile and test of cm3 ... >>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>>>> >>>>>>>> Error: Sending buildlog failed! >>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>> cleaning CM3 workspaces... >>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>> >>>>>>>> cleaning regression test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>> >>>>>>>> cleaning m3test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>> >>>>>>>> cleaning snapshot files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>> >>>>>>>> cleaning package reports... >>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 21:54:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 15:54:49 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: Hmm. This is weird. I already have my own version of date (which accepts +%s) installed in my path so it should just work. My cron jobs sets the path accordingly: #/bin/sh CVS_RSH=ssh PATH=$HOME/bin:/opt/csw/bin:/opt/csw/gcc3/bin:/usr/ccs/bin:$PATH export CVS_RSH export PATH cd $HOME/cm3/scripts/regression ./tinderbox-build.sh cm3.build BUILD_REL=lastok ./tinderbox-build.sh cm3.build so I don't know where this new error is coming from (as Olaf points out tinderbox-build.sh hasn't changed significantly in any way that would trigger an error). Is there some other script not getting my private version $HOME/bin/date? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 25 Jul 2009, at 15:19, Jay K wrote: > > (two occurences of that) > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sat, 25 Jul 2009 19:19:11 +0000 >> >> >> This line: >> >> >> echo tinderbox: timenow: `date +%s` >> >> needs to more like these lines: >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run >> done." >> >> >> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >> 2009.07.25 12:13:54 >> >> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >> 07.25.09 12:14:33 >> >> -bash-3.00$ date +%s >> %s >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> Perhaps I am confusing with the original change I made for 1.10 >>>> to the >>>> parameter to the "date" command. >>>> >>>> In any case, something changed so that my scripts did not run >>>> properly. It's been a long time since I've seen a sane tinderbox >>>> run >>>> for Solaris -- will things be stabilising soon? >>> >>> I broke the last one yesterday with $() (fixed soon afterwards), but >>> the one before succeeded: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>> >>> I was hoping to get a green build from one of your systems today >>> (big-endian, different architecture) to finally fix the RC2 tag. >>> But if you cannot send your results to the tinderbox that will be >>> difficult :-/ I really don't understand why that should have stopped >>> working. >>> >>> The error below seems to be that the reported start time is 0, and >>> that cannot be according to the source. Could you set -x at the >>> start >>> of the tinderbox script and try again? >>> >>> Jay, can you think of anything you have changed that may cause >>> Tony's >>> problem? >>> >>> Olaf >>> >>>> -- Tony (not mobile) >>> :-) >>> >>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> This is an old error for Solaris that I fixed a long time ago. >>>>>> Can >>>>>> someone restore? >>>>> >>>>> Hi Tony, >>>>> >>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>> >>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>> 'STARTTIME| date' >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>> '+%Y %m%d-%H%M%S'`" >>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>> 1.8 (wagner 03-Feb-08): echo " >>>>> date 'date +%s'" >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- compile in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>> %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- tests in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout, compile and test run done." >>>>> >>>>> Nothing at all has changed in these scripts in July: >>>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>> cm3.build cm3.build~ >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/cm3.build >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> >>>>> >>>>> Perhaps I'm looking for the wrong thing. What exactly did you >>>>> change >>>>> long ago to make it work? I'm at a loss now. >>>>> >>>>>> Sent from my iPhone >>>>> >>>>> You seem to be very `mobile' lately ;-) >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Tony Hosking >>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Subject: Output from "cron" command >>>>>>> >>>>>> >>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>> >>>>>>> produced the following output: >>>>>>> >>>>>>> U regression-scripts/defs.sh >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>>>>>> minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 25 21:55:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 15:55:07 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> Message-ID: I've not changed anything on my side. On 25 Jul 2009, at 15:52, Olaf Wagner wrote: > I don't see how that will help us... It worked for Tony for over > a year, and nothing obvious has changed. Or did something change on > your side, Tony (system upgrade, path setting, ...)? > > It's not good to introduce arbitrary changes now without understanding > why it breaks. > > Olaf > > Quoting Jay K : > >> >> Can I suggest the portable scripting language C? >> >> >> -bash-3.00$ cat date.c >> #include >> #include >> #include >> int main() >> { >> printf("%lu\n", (unsigned long)time(NULL)); >> return 0; >> } >> -bash-3.00$ cc date.c -o ./mydate >> -bash-3.00$ ./mydate >> 1248549753 >> -bash-3.00$ pwd >> /dev2/cm3/scripts >> >> >> use that instead? >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> >>> (two occurences of that) >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>> >>>> >>>> This line: >>>> >>>> >>>> echo tinderbox: timenow: `date +%s` >>>> >>>> needs to more like these lines: >>>> >>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>> >>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>> run done." >>>> >>>> >>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>> 2009.07.25 12:13:54 >>>> >>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>> 07.25.09 12:14:33 >>>> >>>> -bash-3.00$ date +%s >>>> %s >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> Perhaps I am confusing with the original change I made for 1.10 >>>>>> to the >>>>>> parameter to the "date" command. >>>>>> >>>>>> In any case, something changed so that my scripts did not run >>>>>> properly. It's been a long time since I've seen a sane >>>>>> tinderbox run >>>>>> for Solaris -- will things be stabilising soon? >>>>> >>>>> I broke the last one yesterday with $() (fixed soon afterwards), >>>>> but >>>>> the one before succeeded: >>>>> >>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>> >>>>> I was hoping to get a green build from one of your systems today >>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>> But if you cannot send your results to the tinderbox that will be >>>>> difficult :-/ I really don't understand why that should have >>>>> stopped >>>>> working. >>>>> >>>>> The error below seems to be that the reported start time is 0, and >>>>> that cannot be according to the source. Could you set -x at the >>>>> start >>>>> of the tinderbox script and try again? >>>>> >>>>> Jay, can you think of anything you have changed that may cause >>>>> Tony's >>>>> problem? >>>>> >>>>> Olaf >>>>> >>>>>> -- Tony (not mobile) >>>>> :-) >>>>> >>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>> >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>> ago. Can >>>>>>>> someone restore? >>>>>>> >>>>>>> Hi Tony, >>>>>>> >>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>> >>>>>>> >>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>> 'STARTTIME| date' >>>>>>> >>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>> *************** >>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>> date 'date +%s'" >>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>> %S'` -- checkout in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>> %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>> %S'` -- checkout, compile and test run done." >>>>>>> >>>>>>> Nothing at all has changed in these scripts in July: >>>>>>> >>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>> >>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>> *************** >>>>>>> luthien [~/work/cm3] wagner >>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>> cm3.build cm3.build~ >>>>>>> luthien [~/work/cm3] wagner >>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>> >>>>>>> Annotations for scripts/regression/cm3.build >>>>>>> *************** >>>>>>> luthien [~/work/cm3] wagner >>>>>>> >>>>>>> >>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you >>>>>>> change >>>>>>> long ago to make it work? I'm at a loss now. >>>>>>> >>>>>>>> Sent from my iPhone >>>>>>> >>>>>>> You seem to be very `mobile' lately ;-) >>>>>>> >>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> From: Tony Hosking >>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Subject: Output from "cron" command >>>>>>>>> >>>>>>>> >>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>> >>>>>>>>> produced the following output: >>>>>>>>> >>>>>>>>> U regression-scripts/defs.sh >>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>> LASTREL=5.4.0 >>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSUSER= >>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>> Building cm3. >>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>> >>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>> log.txt >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>> minutes) >>>>>>>>> >>>>>>>>> Error: Sending buildlog failed! >>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>> cleaning CM3 workspaces... >>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>> >>>>>>>>> cleaning regression test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>> >>>>>>>>> cleaning m3test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>> >>>>>>>>> cleaning snapshot files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>> >>>>>>>>> cleaning package reports... >>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>> >>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>> LASTREL=5.4.0 >>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSUSER= >>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>> Building cm3. >>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>> >>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>> log.txt >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>>>>>>>> minutes) >>>>>>>>> >>>>>>>>> Error: Sending buildlog failed! >>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>> cleaning CM3 workspaces... >>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>> >>>>>>>>> cleaning regression test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>> >>>>>>>>> cleaning m3test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>> >>>>>>>>> cleaning snapshot files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>> >>>>>>>>> cleaning package reports... >>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>> >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>> Sitz: Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>> 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>> IdNr: DE163214194 >>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 22:00:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 22:00:15 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> Message-ID: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Quoting Tony Hosking : > I've not changed anything on my side. I don't understand why I missed that: revision 1.13 date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; let's just try plain date, based on the choices in the error message ---------------------------- But you seem to have fixed it already: revision 1.14 date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: yRpWy2mygKpT88Xt; Revert to what used to work. Strange that it didn't show up in my first diff. Olaf > > On 25 Jul 2009, at 15:52, Olaf Wagner wrote: > >> I don't see how that will help us... It worked for Tony for over >> a year, and nothing obvious has changed. Or did something change on >> your side, Tony (system upgrade, path setting, ...)? >> >> It's not good to introduce arbitrary changes now without understanding >> why it breaks. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Can I suggest the portable scripting language C? >>> >>> >>> -bash-3.00$ cat date.c >>> #include >>> #include >>> #include >>> int main() >>> { >>> printf("%lu\n", (unsigned long)time(NULL)); >>> return 0; >>> } >>> -bash-3.00$ cc date.c -o ./mydate >>> -bash-3.00$ ./mydate >>> 1248549753 >>> -bash-3.00$ pwd >>> /dev2/cm3/scripts >>> >>> >>> use that instead? >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> >>>> (two occurences of that) >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>> >>>>> >>>>> This line: >>>>> >>>>> >>>>> echo tinderbox: timenow: `date +%s` >>>>> >>>>> needs to more like these lines: >>>>> >>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>> >>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>> run done." >>>>> >>>>> >>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>> 2009.07.25 12:13:54 >>>>> >>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>> 07.25.09 12:14:33 >>>>> >>>>> -bash-3.00$ date +%s >>>>> %s >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>> >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>> parameter to the "date" command. >>>>>>> >>>>>>> In any case, something changed so that my scripts did not run >>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>> for Solaris -- will things be stabilising soon? >>>>>> >>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>> the one before succeeded: >>>>>> >>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>> >>>>>> I was hoping to get a green build from one of your systems today >>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>> But if you cannot send your results to the tinderbox that will be >>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>> working. >>>>>> >>>>>> The error below seems to be that the reported start time is 0, and >>>>>> that cannot be according to the source. Could you set -x at the start >>>>>> of the tinderbox script and try again? >>>>>> >>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>> problem? >>>>>> >>>>>> Olaf >>>>>> >>>>>>> -- Tony (not mobile) >>>>>> :-) >>>>>> >>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>> >>>>>>>> Quoting Tony Hosking : >>>>>>>> >>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>> someone restore? >>>>>>>> >>>>>>>> Hi Tony, >>>>>>>> >>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>> >>>>>>>> >>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>> 'STARTTIME| date' >>>>>>>> >>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>> *************** >>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>> date 'date +%s'" >>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>> %S'` -- checkout in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>> >>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>> >>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>> >>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>> *************** >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>> cm3.build cm3.build~ >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>> >>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>> *************** >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> >>>>>>>> >>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>> >>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>>> From: Tony Hosking >>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>> >>>>>>>>>> produced the following output: >>>>>>>>>> >>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSUSER= >>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>> Building cm3. >>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>> >>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>> >>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>> >>>>>>>>>> cleaning regression test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>> >>>>>>>>>> cleaning m3test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>> >>>>>>>>>> cleaning snapshot files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>> >>>>>>>>>> cleaning package reports... >>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>> >>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSUSER= >>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>> Building cm3. >>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>> >>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>> >>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>> >>>>>>>>>> cleaning regression test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>> >>>>>>>>>> cleaning m3test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>> >>>>>>>>>> cleaning snapshot files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>> >>>>>>>>>> cleaning package reports... >>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>> >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>> 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>> Sitz: Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>> DE163214194 >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>> 23 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>> IdNr: DE163214194 >>>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 05:09:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 03:09:59 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: Tony reverted it. I'm bringing my Solaris/sparc machine up to date and will try running Tinderbox. I will likely try with plain date and see what happens there and otherwise. - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 22:00:15 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Quoting Tony Hosking : > >> I've not changed anything on my side. > > I don't understand why I missed that: > > revision 1.13 > date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; > let's just try plain date, based on the choices in the error message > ---------------------------- > > But you seem to have fixed it already: > > revision 1.14 > date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: yRpWy2mygKpT88Xt; > Revert to what used to work. > > Strange that it didn't show up in my first diff. > > Olaf > > >> >> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >> >>> I don't see how that will help us... It worked for Tony for over >>> a year, and nothing obvious has changed. Or did something change on >>> your side, Tony (system upgrade, path setting, ...)? >>> >>> It's not good to introduce arbitrary changes now without understanding >>> why it breaks. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Can I suggest the portable scripting language C? >>>> >>>> >>>> -bash-3.00$ cat date.c >>>> #include >>>> #include >>>> #include >>>> int main() >>>> { >>>> printf("%lu\n", (unsigned long)time(NULL)); >>>> return 0; >>>> } >>>> -bash-3.00$ cc date.c -o ./mydate >>>> -bash-3.00$ ./mydate >>>> 1248549753 >>>> -bash-3.00$ pwd >>>> /dev2/cm3/scripts >>>> >>>> >>>> use that instead? >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>> >>>>> >>>>> (two occurences of that) >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>> >>>>>> >>>>>> This line: >>>>>> >>>>>> >>>>>> echo tinderbox: timenow: `date +%s` >>>>>> >>>>>> needs to more like these lines: >>>>>> >>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>> >>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>> run done." >>>>>> >>>>>> >>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>> 2009.07.25 12:13:54 >>>>>> >>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>> 07.25.09 12:14:33 >>>>>> >>>>>> -bash-3.00$ date +%s >>>>>> %s >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>> From: wagner at elegosoft.com >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>> >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>>> parameter to the "date" command. >>>>>>>> >>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>> >>>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>>> the one before succeeded: >>>>>>> >>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>> >>>>>>> I was hoping to get a green build from one of your systems today >>>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>>> But if you cannot send your results to the tinderbox that will be >>>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>>> working. >>>>>>> >>>>>>> The error below seems to be that the reported start time is 0, and >>>>>>> that cannot be according to the source. Could you set -x at the start >>>>>>> of the tinderbox script and try again? >>>>>>> >>>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>>> problem? >>>>>>> >>>>>>> Olaf >>>>>>> >>>>>>>> -- Tony (not mobile) >>>>>>> :-) >>>>>>> >>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Quoting Tony Hosking : >>>>>>>>> >>>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>>> someone restore? >>>>>>>>> >>>>>>>>> Hi Tony, >>>>>>>>> >>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>> >>>>>>>>> >>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>> 'STARTTIME| date' >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>> *************** >>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>> date 'date +%s'" >>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>> %S'` -- checkout in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>> >>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>> >>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>> *************** >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>> cm3.build cm3.build~ >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>> *************** >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>> >>>>>>>>> >>>>>>>>>> Begin forwarded message: >>>>>>>>>> >>>>>>>>>>> From: Tony Hosking >>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>> >>>>>>>>>>> produced the following output: >>>>>>>>>>> >>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>> Building cm3. >>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>> >>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>>> >>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>> >>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>> >>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>> >>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>> >>>>>>>>>>> cleaning package reports... >>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>> >>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>> Building cm3. >>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>> >>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>> >>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>> >>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>> >>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>> >>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>> >>>>>>>>>>> cleaning package reports... >>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>> Sitz: Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>> DE163214194 >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>> IdNr: DE163214194 >>>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 26 06:23:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 04:23:40 +0000 Subject: [M3devel] "32" in target names? Message-ID: "32" in target names? I introduced: PPC32_OPENBSD PA32_HPUX SPARC32_LINUX Should these be renamed? PPC_OPENBSD SPARC_LINUX PA_HPUX? HPPA_HPUX? In the case of the last two, 64bit targets are a pretty clear possibility -- SPARC64_LINUX, PA64_HPUX?HPPA64_HPUX Less so for PPC64 -- Linux, Darwin, AIX, sure, but PPC64_*BSD doesn't seem to be happening. - Jay From jay.krell at cornell.edu Sun Jul 26 09:25:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 07:25:04 +0000 Subject: [M3devel] Tinderbox/Hudson Message-ID: - The links to my Tinderbox test results don't work. - Why are my Tinderbox status usually yellow even though the logs look ok? Due the missing test results? - I do already have Hudson server running OpenBSD/x86, that was easy, not configured yet (still cross building cm3 and will try a Tinderbox run first instead.) LINUXLIBC6 is yellow, but this looks ok: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 Do they have to be more recent? Or need last release and last ok? I only do last ok. You don't have last release for AMD64_LINUX, it doesn't exist, but are green. Maybe two separate builds are needed? SPARC32_LINUX is yellow but it also looks ok. http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 The most recent completed PPC_LINUX failed to get much of the source tree in the CVS checkout. That happens often. I should probably put in a retry or something.. (Bringing back I386_DARWIN, funny thing there, is that to compile X client, you need Python, and the in-box one isn't new enough, and current doesn't build out of the box because it assumes a full Mac system..still working on it..) - Jay From wagner at elegosoft.com Sun Jul 26 11:10:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 11:10:41 +0200 Subject: [M3devel] "32" in target names? In-Reply-To: References: Message-ID: <20090726111041.dx7sjj2hw44g0gck@mail.elegosoft.com> Quoting Jay K : > "32" in target names? > > I introduced: > PPC32_OPENBSD > PA32_HPUX > SPARC32_LINUX > > > Should these be renamed? > PPC_OPENBSD > SPARC_LINUX > PA_HPUX? HPPA_HPUX? > In the case of the last two, 64bit targets are a pretty clear > possibility -- SPARC64_LINUX, PA64_HPUX?HPPA64_HPUX > Less so for PPC64 -- Linux, Darwin, AIX, sure, but PPC64_*BSD > doesn't seem to be happening. I vote for keeping a clear distinction, so keep the 32. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Jul 26 11:17:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 11:17:49 +0200 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: References: Message-ID: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Quoting Jay K : > - The links to my Tinderbox test results don't work. > > - Why are my Tinderbox status usually yellow even though the logs look ok? > Due the missing test results? > > - I do already have Hudson server running OpenBSD/x86, that was > easy, not configured yet (still cross building cm3 and will try a > Tinderbox run first instead.) > > LINUXLIBC6 is yellow, but this looks ok: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 > > Do they have to be more recent? Or need last release and last ok? > I only do last ok. You don't have last release for AMD64_LINUX, it > doesn't exist, but are green. > Maybe two separate builds are needed? > > SPARC32_LINUX is yellow but it also looks ok. > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 Tinderbox shows running builds that haven't complete yet in yellow. Results are either green, red, or orange. So the result transfer to the server may have failed. > The most recent completed PPC_LINUX failed to get much of the source > tree in the CVS checkout. That happens often. I should probably put > in a retry or something.. No. You should probably do something about your network connection ;-) BTW, the exit you put in after the cvs checkout won't work this way. Unless you use special bash pipe result evaluation, it's always the _last_ process in a pipe that determines its result code. > (Bringing back I386_DARWIN, funny thing there, is that to compile X > client, you need Python, and the in-box one isn't new enough, and > current doesn't build out of the box because it assumes a full Mac > system..still working on it..) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 11:19:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 09:19:42 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: Looking at your Hudson jobs..to create my own.. I notice you run test_m3tests manually. I'll try that. Maybe of the yellow jobs ran to completion..but maybe because I didn't run test_m3tests? - Jay ---------------------------------------- > Date: Sun, 26 Jul 2009 11:17:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Tinderbox/Hudson > > Quoting Jay K : > >> - The links to my Tinderbox test results don't work. >> >> - Why are my Tinderbox status usually yellow even though the logs look ok? >> Due the missing test results? >> >> - I do already have Hudson server running OpenBSD/x86, that was >> easy, not configured yet (still cross building cm3 and will try a >> Tinderbox run first instead.) >> >> LINUXLIBC6 is yellow, but this looks ok: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >> >> Do they have to be more recent? Or need last release and last ok? >> I only do last ok. You don't have last release for AMD64_LINUX, it >> doesn't exist, but are green. >> Maybe two separate builds are needed? >> >> SPARC32_LINUX is yellow but it also looks ok. >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 > > Tinderbox shows running builds that haven't complete yet in yellow. > Results are either green, red, or orange. So the result transfer to > the server may have failed. > >> The most recent completed PPC_LINUX failed to get much of the source >> tree in the CVS checkout. That happens often. I should probably put >> in a retry or something.. > > No. You should probably do something about your network connection ;-) > > BTW, the exit you put in after the cvs checkout won't work this way. > Unless you use special bash pipe result evaluation, it's always the > _last_ process in a pipe that determines its result code. > >> (Bringing back I386_DARWIN, funny thing there, is that to compile X >> client, you need Python, and the in-box one isn't new enough, and >> current doesn't build out of the box because it assumes a full Mac >> system..still working on it..) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 26 12:07:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 10:07:51 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: I'm running Tinderbox on SOLgnu now. It fails with that error without a change and gets past the first email if I change the date commands. The first cvs checkout eventually failed, trying again.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Fwd: Output from "cron" command > Date: Sun, 26 Jul 2009 03:09:59 +0000 > > > Tony reverted it. I'm bringing my Solaris/sparc machine up to date and will try running Tinderbox. > I will likely try with plain date and see what happens there and otherwise. > > - Jay > > > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 22:00:15 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Quoting Tony Hosking : >> >>> I've not changed anything on my side. >> >> I don't understand why I missed that: >> >> revision 1.13 >> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >> let's just try plain date, based on the choices in the error message >> ---------------------------- >> >> But you seem to have fixed it already: >> >> revision 1.14 >> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >> Revert to what used to work. >> >> Strange that it didn't show up in my first diff. >> >> Olaf >> >> >>> >>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>> >>>> I don't see how that will help us... It worked for Tony for over >>>> a year, and nothing obvious has changed. Or did something change on >>>> your side, Tony (system upgrade, path setting, ...)? >>>> >>>> It's not good to introduce arbitrary changes now without understanding >>>> why it breaks. >>>> >>>> Olaf >>>> >>>> Quoting Jay K : >>>> >>>>> >>>>> Can I suggest the portable scripting language C? >>>>> >>>>> >>>>> -bash-3.00$ cat date.c >>>>> #include >>>>> #include >>>>> #include >>>>> int main() >>>>> { >>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>> return 0; >>>>> } >>>>> -bash-3.00$ cc date.c -o ./mydate >>>>> -bash-3.00$ ./mydate >>>>> 1248549753 >>>>> -bash-3.00$ pwd >>>>> /dev2/cm3/scripts >>>>> >>>>> >>>>> use that instead? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>> >>>>>> >>>>>> (two occurences of that) >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>> >>>>>>> >>>>>>> This line: >>>>>>> >>>>>>> >>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>> >>>>>>> needs to more like these lines: >>>>>>> >>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>> >>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>> run done." >>>>>>> >>>>>>> >>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>> 2009.07.25 12:13:54 >>>>>>> >>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>> 07.25.09 12:14:33 >>>>>>> >>>>>>> -bash-3.00$ date +%s >>>>>>> %s >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>> From: wagner at elegosoft.com >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>> >>>>>>>> Quoting Tony Hosking : >>>>>>>> >>>>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>>>> parameter to the "date" command. >>>>>>>>> >>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>> >>>>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>>>> the one before succeeded: >>>>>>>> >>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>> >>>>>>>> I was hoping to get a green build from one of your systems today >>>>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>>>> But if you cannot send your results to the tinderbox that will be >>>>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>>>> working. >>>>>>>> >>>>>>>> The error below seems to be that the reported start time is 0, and >>>>>>>> that cannot be according to the source. Could you set -x at the start >>>>>>>> of the tinderbox script and try again? >>>>>>>> >>>>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>>>> problem? >>>>>>>> >>>>>>>> Olaf >>>>>>>> >>>>>>>>> -- Tony (not mobile) >>>>>>>> :-) >>>>>>>> >>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>> >>>>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>>>> someone restore? >>>>>>>>>> >>>>>>>>>> Hi Tony, >>>>>>>>>> >>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>> *************** >>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>> date 'date +%s'" >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>> >>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>> >>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>> *************** >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>> *************** >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Begin forwarded message: >>>>>>>>>>> >>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>> >>>>>>>>>>>> produced the following output: >>>>>>>>>>>> >>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>> Building cm3. >>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>> >>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>>>> >>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>> >>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>>> >>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>> >>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>> Building cm3. >>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>> >>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>> >>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>> >>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>>> >>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>> 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>> Sitz: Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>>> DE163214194 >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>> 23 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>> IdNr: DE163214194 >>>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sun Jul 26 12:49:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 12:49:49 +0200 Subject: [M3devel] CM3 release engineering status Message-ID: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> Here's the current status: * release branch created for 5.8 * Hudson continuous integration and Tinderbox default checkout changed to the release branch by default (instances out of my control) * end of code freeze on main trunk (seems it never crossed the 0 degree Celsius boundary anyway :-) * commit restriction for the release branch: - contact me for including changes there - needed: CVS start and end tag exactly identifying the change set to be included * reviewed all package test failures and fixed them (for FreeBSD4 and AMD64_LINUX) * only known good target platforms currently are FreeBSD4 and AMD64_LINUX * need status for at least LINUXLIBC6, NT386, SOLgnu additionally * will try to setup more regression testing under my control during the next week(s) * RC2 postponed until end of next week... hopefully we'll know more then see also https://projects.elego.de/cm3/roadmap and http://hudson.modula3.com:8080/view/cm3/ Thanks for your attention and cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 13:04:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 11:04:06 +0000 Subject: [M3devel] new errors wrt bc and [ Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248604850.21111 1) m3gdb/src/m3makefile gnu platform missing, I fixed it 2a) "/home/jay/work/cm3-ws/sparc3-2009-07-26-03-59-12/cm3/m3-sys/m3tests/src/m3makefile", line 279: quake runtime error: execution failed: execution of `bc? failed: errno=2 2b) /home/jay/work/cm3-ws/sparc3-2009-07-26-03-59-12/cm3/scripts/pkgmap.sh: line 360: bc: command not found 3) regression-scripts/defs.sh: line 776: [: too many arguments if [ "${TESTHOSTNAME}" = "birch.elegosoft.com" -a `who -m | cut -d ' ' -f1` = "m3" ]; then Maybe put an "x" in there? if [ "x${TESTHOSTNAME}" = "xbirch.elegosoft.com" -a `who -m | cut -d ' ' -f1` = "m3" ]; then ? (+2 for using Python..) - Jay From jay.krell at cornell.edu Sun Jul 26 14:48:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 12:48:20 +0000 Subject: [M3devel] the formsedit crash Message-ID: Ok here is the formsedit crash. This is on SOLgnu. I have also seen it on either PPC_DARWIN or PPC_LINUX. I can try those again. It doesn't happen every time, but some large fraction, like maybe half. I changed the SIGsEGV to an assertion failure. -bash-3.00$ export DISPLAY=192.168.1.120:0.0 -bash-3.00$ ./formsedit *** *** runtime error: *** failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 *** Abort (core dumped) You can't debug it live because you keep getting interrupted by sig usr2. -bash-3.00$ dbx formsedit core t at 1 (l at 1) terminated by signal KILL (Killed) 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! 0xfe3c00a4 These statements from the debugger about main/AddUnit don't make sense to me. Current function is main 13 RTLinker__AddUnit (FormsEdit_M3); (dbx) where current thread: t at 1 [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xfe4680b8 [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xfe467ca0 [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xfefa5adc Does the code really recurse like this? [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, 0xffbf9ca0, 0xfe4a5d 00, 0xfef48180), at 0xfef48520 [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, 0xff000000, 0x0, 0x0 ), at 0xff046ea4 [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, 0xffbf9e48, 0x0, 0xfefbcf58), at 0xfefbcf84 [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, 0xffbf9f18, 0 x0, 0xff0437d8), at 0xff043864 [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, 0x0, 0x0), at 0xff046ea4 [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, 0xffbfa0a8, 0x0, 0xfefbcf58), at 0xfefbcf84 [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, 0x0, 0x0), at 0xff046ea4 [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, 0xffbfa238, 0x0, 0xfefbcf58), at 0xfefbcf84 [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, 0x0, 0x0), at 0xff046ea4 [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, 0xffbfa3c8, 0x0, 0xfefbcf58), at 0xfefbcf84 [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, 0x0, 0x0), at 0xff046ea4 [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, 0xffbfa558, 0x0, 0xfefbcf58), at 0xfefbcf84 [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, 0x0, 0x0), at 0xff046ea4 [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, 0xffbfa6e8, 0x0, 0xfefbcf58), at 0xfefbcf84 [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, 0x0, 0x0), at 0xff046ea4 [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, 0xffbfa878, 0x0, 0xfefbcf58), at 0xfefbcf84 [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, 0x0, 0x0), at 0xff046ea4 [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, 0xffbfaa08, 0x0, 0xfefbcf58), at 0xfefbcf84 [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, 0x0, 0x0), at 0xff046ea4 [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, 0xffbfab98, 0x0, 0xfefbcf58), at 0xfefbcf84 [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, 0x0, 0x0), at 0xff046ea4 [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, 0xffbfad28, 0x0, 0xfefbcf58), at 0xfefbcf84 [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, 0x0, 0x0), at 0xff046ea4 [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, 0xffbfaeb8, 0x0, 0xfefbcf58), at 0xfefbcf84 [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, 0x0, 0x0), at 0xff046ea4 [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, 0xffbfb048, 0x0, 0xfefbcf58), at 0xfefbcf84 [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, 0x0, 0x0), at 0xff046ea4 [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, 0xffbfb1d8, 0x0, 0xfefbcf58), at 0xfefbcf84 [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, 0x0, 0x0), at 0xff046ea4 [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, 0xffbfb368, 0x0, 0xfefbcf58), at 0xfefbcf84 [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, 0x0, 0x0), at 0xff046ea4 [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, 0xffbfb4f8, 0x0, 0xfefbcf58), at 0xfefbcf84 [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, 0x0, 0x0), at 0xff046ea4 [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, 0xffbfb688, 0x0, 0xfefbcf58), at 0xfefbcf84 [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, 0x0, 0x0), at 0xff046ea4 [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, 0xffbfb818, 0x0, 0xfefbcf58), at 0xfefbcf84 [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, 0x0, 0x0), at 0xff046ea4 [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, 0xffbfb9a8, 0x0, 0xfefbcf58), at 0xfefbcf84 [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, 0x0, 0x0), at 0xff046ea4 [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, 0xffbfbb38, 0x0, 0xfefbcf58), at 0xfefbcf84 [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, 0x0, 0x0), at 0xff046ea4 [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, 0xffbfbcc8, 0x0, 0xfefbcf58), at 0xfefbcf84 [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, 0x0, 0x0), at 0xff046ea4 [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, 0xffbfbe58, 0x0, 0xfefbcf58), at 0xfefbcf84 [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, 0x0, 0x0), at 0xff046ea4 [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, 0xffbfbfe8, 0x0, 0xfefbcf58), at 0xfefbcf84 [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, 0x0, 0x0), at 0xff046ea4 [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, 0xffbfc178, 0x0, 0xfefbcf58), at 0xfefbcf84 [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, 0x0, 0x0), at 0xff046ea4 [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, 0xffbfc308, 0x0, 0xfefbcf58), at 0xfefbcf84 [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, 0x0, 0x0), at 0xff046ea4 [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, 0xffbfc498, 0x0, 0xfefbcf58), at 0xfefbcf84 [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, 0xfe1b2000, 0x6b170 , 0x0), at 0xff046ea4 [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, 0xff000000, 0x0, 0x0), at 0xff191d20 [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b27 0, 0x0), at 0xfefb6a38 [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d00, 0x0), at 0xfefbc9f4 [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, 0xfe1b2000, 0x6b290, 0x0), at 0xfefbc9f4 [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b2b 0, 0x0), at 0xfefb6a38 [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d00, 0x0), at 0xfefbc9f4 [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, 0xfe1b2000, 0x6b2d0, 0x0), at 0xfefbc9f4 [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6af7 0, 0x0), at 0xfefb6a38 [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, 0xff000000, 0x0, 0x0), at 0xfefbc9f4 [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b33 0, 0x0), at 0xfefb6a38 [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, 0xfe1b2000, 0x6b698, 0x0), at 0xfefbc9f4 [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, 0xfe1b2000, 0x6b69 8, 0x0), at 0xfefbc9f4 [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, 0xfe1b2000, 0xf e4a5d00, 0x0), at 0xfefeb348 [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, 0xfe1b2000, 0x6b6b8, 0x0), at 0xfefbc9f4 [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b7f 8, 0x0), at 0xfefb6a38 [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, 0xfe1b2000, 0x6b858, 0x0), at 0xfefbc9f4 [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, 0x0, 0x0), at 0xfefb6a38 [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, 0xfe1b2000, 0x6b858, 0x0), at 0xfefbc9f4 [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, 0xff000000, 0x0 , 0x0), at 0xff18d2ec [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b87 8, 0x0), at 0xfefb6a38 [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b898, 0x0), at 0xfefbc9f4 [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, 0xfe1b2000, 0x6b89 8, 0x0), at 0xfefbc9f4 [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, 0xfe1b2000, 0x6 b8b8, 0x0), at 0xfefeb348 [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, 0x20, 0xffbfd b20), at 0xfefb6a38 [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, 0xfe1b2000, 0x6b8b8, 0x0), at 0xfefbc9f4 [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xff01f884 [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, 0xfe1b2000, 0x6b8d8, 0x0), at 0xfefbc9f4 [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xff19e338 [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, 0xfe1b2000, 0x60338, 0x0), at 0xfefbc9f4 [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d 00, 0x0), at 0xfeff6db4 [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, 0xfe1b2000 , 0x6e5a0, 0x0), at 0xfefbc9f4 (dbx) (dbx) threads > t at 1 a l at 1 ?() LWP suspended in __lwp_park() t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in ___nanosleep () t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 in __lwp_pa rk() t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in ___nanosleep () t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 in __lwp_pa rk() t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 in __lwp_pa rk() t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 in __lwp_pa rk() o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in __lwp_kill( ) t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 in __lwp_pa rk() (dbx) The crashing thread: (dbx) thread t at 27 t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe3c11f4 (dbx) where current thread: t at 27 =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at 0xfe35fdd8 [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at 0xfe33fff8 [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at 0xfe46255c [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at 0xfe4529c8 [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, 0xfddf0900), at 0x fe44f2e4 [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, 0xfe4b4d90, 0xff2 50434), at 0xfe44ee5c [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, 0x100000), at 0xfe44fa0c [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678), at 0xfe44f590 [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc53131), at 0xfe44f44c [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, 0x0), at 0xfe46 470c [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678), at 0xfe44f680 [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc53661), at 0xfe44f44c [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc538 e1), at 0xfe46470c [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, 0xfdc53a40, 0xfdc539 2c, 0xfdc53928), at 0xfe42ffe0 [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, 0xfdc53a40), a t 0xff141d64 (too many frames for an assertion failure imho!) [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xff13dda4 [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, 0xff000000, 0x0, 0x0), at 0xff13d9e8 [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, 0xfddf0800, 0x69da0, 0x0), at 0xff140730 [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0xff000000, 0xff00000 0, 0x0, 0x1), at 0xff1407d0 [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, 0xfdd221bc), a t 0xfefb8f04 [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at 0xfefc5170 [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, 0xfddf0800, 0x90 410, 0x0), at 0xfefc45a8 [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfefc4674 [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at 0xfe46bc00 [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, 0xfe46b740, 0x1) , at 0xfe46b790 (dbx) - Jay From jay.krell at cornell.edu Sun Jul 26 16:10:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 14:10:50 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: I don't think that is it but I don't know. I don't know the various paths through the scripts, haven't studied them enough.. for some reason my one run on SOLgnu did run the tests and turned green. Most of my runs stop after successful compile so stay yellow. I edited out that one line you said to. Maybe I should an -x run. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Tinderbox/Hudson > Date: Sun, 26 Jul 2009 09:19:42 +0000 > > > Looking at your Hudson jobs..to create my own.. I notice you run test_m3tests manually. I'll try that. > Maybe of the yellow jobs ran to completion..but maybe because I didn't run test_m3tests? > > - Jay > > > > ---------------------------------------- >> Date: Sun, 26 Jul 2009 11:17:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Tinderbox/Hudson >> >> Quoting Jay K : >> >>> - The links to my Tinderbox test results don't work. >>> >>> - Why are my Tinderbox status usually yellow even though the logs look ok? >>> Due the missing test results? >>> >>> - I do already have Hudson server running OpenBSD/x86, that was >>> easy, not configured yet (still cross building cm3 and will try a >>> Tinderbox run first instead.) >>> >>> LINUXLIBC6 is yellow, but this looks ok: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >>> >>> Do they have to be more recent? Or need last release and last ok? >>> I only do last ok. You don't have last release for AMD64_LINUX, it >>> doesn't exist, but are green. >>> Maybe two separate builds are needed? >>> >>> SPARC32_LINUX is yellow but it also looks ok. >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 >> >> Tinderbox shows running builds that haven't complete yet in yellow. >> Results are either green, red, or orange. So the result transfer to >> the server may have failed. >> >>> The most recent completed PPC_LINUX failed to get much of the source >>> tree in the CVS checkout. That happens often. I should probably put >>> in a retry or something.. >> >> No. You should probably do something about your network connection ;-) >> >> BTW, the exit you put in after the cvs checkout won't work this way. >> Unless you use special bash pipe result evaluation, it's always the >> _last_ process in a pipe that determines its result code. >> >>> (Bringing back I386_DARWIN, funny thing there, is that to compile X >>> client, you need Python, and the in-box one isn't new enough, and >>> current doesn't build out of the box because it assumes a full Mac >>> system..still working on it..) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sun Jul 26 19:16:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 17:16:49 +0000 Subject: [M3devel] libz in Tinderbox? Message-ID: Tony can you install libz? Or should we import it? Or should we maybe probe for $HOME/lib/libz.a or somewhere else? http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake runtime error: file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib 22072 There is also: Must be attached to terminal for ?am I? option 49575 + [ niagara = birch.elegosoft.com -a = m3 ] 49576 ./tinderbox-build.sh: test: argument expected 49577 r4=1 49578 + expr 0 + 0 + 255 + 255 + 1 49579 + return 511 49580 + date +%Y.%m.%d %H:%M:%S 49581 + echo [end run-tests 2009.07.26 10:39:00] 49582 [end run-tests 2009.07.26 10:39:00] 49583 *** TESTS FAILED - Jay From hosking at cs.purdue.edu Sun Jul 26 19:44:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:44:39 -0400 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> It did not used to be required that to build X clients on I386_DARWIN you needed Python. What changed? Sent from my iPhone On Jul 26, 2009, at 5:17 AM, Olaf Wagner wrote: > Quoting Jay K : > >> - The links to my Tinderbox test results don't work. >> >> - Why are my Tinderbox status usually yellow even though the logs >> look ok? >> Due the missing test results? >> >> - I do already have Hudson server running OpenBSD/x86, that was >> easy, not configured yet (still cross building cm3 and will try a >> Tinderbox run first instead.) >> >> LINUXLIBC6 is yellow, but this looks ok: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >> >> Do they have to be more recent? Or need last release and last ok? >> I only do last ok. You don't have last release for AMD64_LINUX, it >> doesn't exist, but are green. >> Maybe two separate builds are needed? >> >> SPARC32_LINUX is yellow but it also looks ok. >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 > > Tinderbox shows running builds that haven't complete yet in yellow. > Results are either green, red, or orange. So the result transfer to > the server may have failed. > >> The most recent completed PPC_LINUX failed to get much of the >> source tree in the CVS checkout. That happens often. I should >> probably put in a retry or something.. > > No. You should probably do something about your network connection ;-) > > BTW, the exit you put in after the cvs checkout won't work this way. > Unless you use special bash pipe result evaluation, it's always the > _last_ process in a pipe that determines its result code. > >> (Bringing back I386_DARWIN, funny thing there, is that to compile >> X client, you need Python, and the in-box one isn't new enough, >> and current doesn't build out of the box because it assumes a full >> Mac system..still working on it..) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Sun Jul 26 19:48:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:48:35 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> I have not changed my tinderbox install on niagara for over a year and it suddenly stopped working so the problem must be with some recent commit. Note that I installed the GNU binutils way back when (over a year ago) so that things would work with 'date +%s'. Sent from my iPhone On Jul 26, 2009, at 6:07 AM, Jay K wrote: > > I'm running Tinderbox on SOLgnu now. > It fails with that error without a change and gets past the first > email if I change the date commands. > The first cvs checkout eventually failed, trying again.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sun, 26 Jul 2009 03:09:59 +0000 >> >> >> Tony reverted it. I'm bringing my Solaris/sparc machine up to date >> and will try running Tinderbox. >> I will likely try with plain date and see what happens there and >> otherwise. >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 22:00:15 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> I've not changed anything on my side. >>> >>> I don't understand why I missed that: >>> >>> revision 1.13 >>> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >>> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >>> let's just try plain date, based on the choices in the error message >>> ---------------------------- >>> >>> But you seem to have fixed it already: >>> >>> revision 1.14 >>> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >>> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >>> Revert to what used to work. >>> >>> Strange that it didn't show up in my first diff. >>> >>> Olaf >>> >>> >>>> >>>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>>> >>>>> I don't see how that will help us... It worked for Tony for over >>>>> a year, and nothing obvious has changed. Or did something change >>>>> on >>>>> your side, Tony (system upgrade, path setting, ...)? >>>>> >>>>> It's not good to introduce arbitrary changes now without >>>>> understanding >>>>> why it breaks. >>>>> >>>>> Olaf >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> >>>>>> Can I suggest the portable scripting language C? >>>>>> >>>>>> >>>>>> -bash-3.00$ cat date.c >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> int main() >>>>>> { >>>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>>> return 0; >>>>>> } >>>>>> -bash-3.00$ cc date.c -o ./mydate >>>>>> -bash-3.00$ ./mydate >>>>>> 1248549753 >>>>>> -bash-3.00$ pwd >>>>>> /dev2/cm3/scripts >>>>>> >>>>>> >>>>>> use that instead? >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>> >>>>>>> >>>>>>> (two occurences of that) >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>>> >>>>>>>> >>>>>>>> This line: >>>>>>>> >>>>>>>> >>>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>>> >>>>>>>> needs to more like these lines: >>>>>>>> >>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>>> >>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>>> run done." >>>>>>>> >>>>>>>> >>>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>>> 2009.07.25 12:13:54 >>>>>>>> >>>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>>> 07.25.09 12:14:33 >>>>>>>> >>>>>>>> -bash-3.00$ date +%s >>>>>>>> %s >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>>> From: wagner at elegosoft.com >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>>> >>>>>>>>> Quoting Tony Hosking : >>>>>>>>> >>>>>>>>>> Perhaps I am confusing with the original change I made for >>>>>>>>>> 1.10 to the >>>>>>>>>> parameter to the "date" command. >>>>>>>>>> >>>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>>> properly. It's been a long time since I've seen a sane >>>>>>>>>> tinderbox run >>>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>>> >>>>>>>>> I broke the last one yesterday with $() (fixed soon >>>>>>>>> afterwards), but >>>>>>>>> the one before succeeded: >>>>>>>>> >>>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>>> >>>>>>>>> I was hoping to get a green build from one of your systems >>>>>>>>> today >>>>>>>>> (big-endian, different architecture) to finally fix the RC2 >>>>>>>>> tag. >>>>>>>>> But if you cannot send your results to the tinderbox that >>>>>>>>> will be >>>>>>>>> difficult :-/ I really don't understand why that should have >>>>>>>>> stopped >>>>>>>>> working. >>>>>>>>> >>>>>>>>> The error below seems to be that the reported start time is >>>>>>>>> 0, and >>>>>>>>> that cannot be according to the source. Could you set -x at >>>>>>>>> the start >>>>>>>>> of the tinderbox script and try again? >>>>>>>>> >>>>>>>>> Jay, can you think of anything you have changed that may >>>>>>>>> cause Tony's >>>>>>>>> problem? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>>> -- Tony (not mobile) >>>>>>>>> :-) >>>>>>>>> >>>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>>> >>>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>>> >>>>>>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>>>>>> ago. Can >>>>>>>>>>>> someone restore? >>>>>>>>>>> >>>>>>>>>>> Hi Tony, >>>>>>>>>>> >>>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>> *************** >>>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>>> date 'date +%s'" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: >>>>>>>>>>> $STARTTIME >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>>> >>>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>>> >>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>> Jul-09 >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>> *************** >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>>> *************** >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did >>>>>>>>>>> you change >>>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>> >>>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>>> >>>>>>>>>>>>> produced the following output: >>>>>>>>>>>>> >>>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>>> >>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>>>>>> log.txt >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: >>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>> clock >>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>> time. >>>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>>>>>> minutes) >>>>>>>>>>>>> >>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023- >>>>>>>>>>>>> tVaq2V ... >>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>> *.tgz >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>> >>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>>> >>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>>>>>> log.txt >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: >>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>> clock >>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>> time. >>>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>>> >>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032- >>>>>>>>>>>>> xba4dW ... >>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>> *.tgz >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>>> 45 86 95 >>>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>>> Sitz: Berlin >>>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>>> IdNr: >>>>>>>>>>> DE163214194 >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wag >>>>>>>>> ner | Sitz: Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>> IdNr: DE163214194 >>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Si >>>>> tz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> From hosking at cs.purdue.edu Sun Jul 26 19:50:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:50:34 -0400 Subject: [M3devel] CM3 release engineering status In-Reply-To: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> References: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> Message-ID: <47F8AD91-A3A4-41F6-BB4C-4705BB2DD5DB@cs.purdue.edu> +I386_DARWIN right? Sent from my iPhone On Jul 26, 2009, at 6:49 AM, Olaf Wagner wrote: > Here's the current status: > > * release branch created for 5.8 > * Hudson continuous integration and Tinderbox default checkout > changed to the release branch by default (instances out of my > control) > * end of code freeze on main trunk (seems it never crossed the 0 > degree > Celsius boundary anyway :-) > * commit restriction for the release branch: > - contact me for including changes there > - needed: CVS start and end tag exactly identifying the change set > to be included > * reviewed all package test failures and fixed them (for FreeBSD4 and > AMD64_LINUX) > * only known good target platforms currently are FreeBSD4 and > AMD64_LINUX > * need status for at least LINUXLIBC6, NT386, SOLgnu additionally > * will try to setup more regression testing under my control during > the next week(s) > * RC2 postponed until end of next week... hopefully we'll know more > then > > see also https://projects.elego.de/cm3/roadmap > and http://hudson.modula3.com:8080/view/cm3/ > > Thanks for your attention and cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Sun Jul 26 19:57:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:57:07 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: Message-ID: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Stack overflow? And yes, I have seen deep recursions like that. What happens if you use a deeper stack? Sent from my iPhone On Jul 26, 2009, at 8:48 AM, Jay K wrote: > > Ok here is the formsedit crash. > This is on SOLgnu. I have also seen it on either PPC_DARWIN or > PPC_LINUX. > I can try those again. > > > It doesn't happen every time, but some large fraction, like maybe > half. > I changed the SIGsEGV to an assertion failure. > > > -bash-3.00$ export DISPLAY=192.168.1.120:0.0 > -bash-3.00$ ./formsedit > > *** > *** runtime error: > *** failed. > *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 > *** > Abort (core dumped) > > You can't debug it live because you keep getting interrupted by sig > usr2. > > -bash-3.00$ dbx formsedit core > > t at 1 (l at 1) terminated by signal KILL (Killed) > 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! > 0xfe3c00a4 > > These statements from the debugger about main/AddUnit don't make > sense to me. > > Current function is main > 13 RTLinker__AddUnit (FormsEdit_M3); > > (dbx) where > current thread: t at 1 > [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 > [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 > [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xfe4680b8 > [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at > 0xfe467ca0 > [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at > 0xfefa5adc > > Does the code really recurse like this? > > [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, > 0xffbf9ca0, 0xfe4a5d > 00, 0xfef48180), at 0xfef48520 > [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, > 0xff000000, 0x0, 0x0 > ), at 0xff046ea4 > [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, > 0xffbf9e48, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, > 0xffbf9f18, 0 > x0, 0xff0437d8), at 0xff043864 > [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, > 0xffbfa0a8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, > 0xffbfa238, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, > 0xffbfa3c8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, > 0xffbfa558, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, > 0xffbfa6e8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, > 0xffbfa878, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, > 0xffbfaa08, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, > 0xffbfab98, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, > 0xffbfad28, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, > 0xffbfaeb8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, > 0xffbfb048, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, > 0xffbfb1d8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, > 0xffbfb368, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, > 0xffbfb4f8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, > 0xffbfb688, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, > 0xffbfb818, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, > 0xffbfb9a8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, > 0xffbfbb38, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, > 0xffbfbcc8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, > 0xffbfbe58, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, > 0xffbfbfe8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, > 0xffbfc178, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, > 0xffbfc308, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, > 0xffbfc498, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, > 0xfe1b2000, 0x6b170 > , 0x0), at 0xff046ea4 > [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, > 0xff000000, > 0x0, 0x0), at 0xff191d20 > [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b27 > 0, 0x0), at 0xfefb6a38 > [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, > 0xfe1b2000, > 0xfe4a5d00, 0x0), at 0xfefbc9f4 > [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b290, 0x0), at 0xfefbc9f4 > [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b2b > 0, 0x0), at 0xfefb6a38 > [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, > 0xfe1b2000, > 0xfe4a5d00, 0x0), at 0xfefbc9f4 > [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b2d0, 0x0), at 0xfefbc9f4 > [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6af7 > 0, 0x0), at 0xfefb6a38 > [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, > 0xff000000, > 0x0, 0x0), at 0xfefbc9f4 > [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b33 > 0, 0x0), at 0xfefb6a38 > [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b698, 0x0), at 0xfefbc9f4 > [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, > 0xfe1b2000, 0x6b69 > 8, 0x0), at 0xfefbc9f4 > [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, > 0xfe1b2000, 0xf > e4a5d00, 0x0), at 0xfefeb348 > [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b6b8, 0x0), at 0xfefbc9f4 > [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b7f > 8, 0x0), at 0xfefb6a38 > [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b858, 0x0), at 0xfefbc9f4 > [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, > 0x0, 0x0), at > 0xfefb6a38 > [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b858, 0x0), at 0xfefbc9f4 > [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, > 0xff000000, 0x0 > , 0x0), at 0xff18d2ec > [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b87 > 8, 0x0), at 0xfefb6a38 > [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b898, 0x0), at 0xfefbc9f4 > [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, > 0xfe1b2000, 0x6b89 > 8, 0x0), at 0xfefbc9f4 > [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, > 0xfe1b2000, 0x6 > b8b8, 0x0), at 0xfefeb348 > [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, > 0x20, 0xffbfd > b20), at 0xfefb6a38 > [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, > 0xfe1b2000, > 0x6b8b8, 0x0), at 0xfefbc9f4 > [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xff01f884 > [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b8d8, 0x0), at 0xfefbc9f4 > [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xff19e338 > [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, > 0xfe1b2000, > 0x60338, 0x0), at 0xfefbc9f4 > [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4a5d > 00, 0x0), at 0xfeff6db4 > [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, > 0xfe1b2000 > , 0x6e5a0, 0x0), at 0xfefbc9f4 > (dbx) > (dbx) threads >> t at 1 a l at 1 ?() LWP suspended in __lwp_park() > t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in > ___nanosleep > () > t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 > in __lwp_pa > rk() > t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in > ___nanosleep > () > t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 > in __lwp_pa > rk() > t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 > in __lwp_pa > rk() > t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 > in __lwp_pa > rk() > o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in > __lwp_kill( > ) > t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 > in __lwp_pa > rk() > (dbx) > > > The crashing thread: > > (dbx) thread t at 27 > t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 > 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xfe3c11f4 > (dbx) where > current thread: t at 27 > =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 > [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at > 0xfe35fdd8 > [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at > 0xfe33fff8 > [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at > 0xfe46255c > [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at > 0xfe4529c8 > [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, > 0xfddf0900), at 0x > fe44f2e4 > [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, > 0xfe4b4d90, 0xff2 > 50434), at 0xfe44ee5c > [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, > 0x100000), > at 0xfe44fa0c > [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 > ), > at 0xfe44f590 > [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, > 0xfffffff8, 0x0, > 0xfdc53131), at 0xfe44f44c > [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, > 0x0), at 0xfe46 > 470c > [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 > ), > at 0xfe44f680 > [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, > 0xfffffff8, 0x0, > 0xfdc53661), at 0xfe44f44c > [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, > 0x0, 0xfdc538 > e1), at 0xfe46470c > [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, > 0xfdc53a40, 0xfdc539 > 2c, 0xfdc53928), at 0xfe42ffe0 > [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, > 0xfdc53a40), a > t 0xff141d64 > > (too many frames for an assertion failure imho!) > > > [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, > 0x1000, 0x0, > 0x0), at 0xff13dda4 > [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, > 0xff000000, 0x0, > 0x0), at 0xff13d9e8 > [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, > 0xfddf0800, > 0x69da0, 0x0), at 0xff140730 > [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, > 0xff000000, 0xff00000 > 0, 0x0, 0x1), at 0xff1407d0 > [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, > 0xfdd221bc), a > t 0xfefb8f04 > [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at > 0xfefc5170 > [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, > 0xfddf0800, 0x90 > 410, 0x0), at 0xfefc45a8 > [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at > 0xfefc4674 > [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at > 0xfe46bc00 > [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, > 0xfe46b740, 0x1) > , at 0xfe46b790 > (dbx) > > > - Jay From jay.krell at cornell.edu Sun Jul 26 19:57:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 17:57:14 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> Message-ID: X clients as in the X client libraries themselves Xlib.so et. al. -- as opposed to the X server. Actually apparently Xlib has been partly replaced by xcb, X C bindings. It is not a Modula-3 thing. But it is interesting imho. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Sun, 26 Jul 2009 13:44:39 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] Tinderbox/Hudson > > It did not used to be required that to build X clients on I386_DARWIN > you needed Python. What changed? > > Sent from my iPhone > > On Jul 26, 2009, at 5:17 AM, Olaf Wagner wrote: > >> Quoting Jay K : >> >>> - The links to my Tinderbox test results don't work. >>> >>> - Why are my Tinderbox status usually yellow even though the logs >>> look ok? >>> Due the missing test results? >>> >>> - I do already have Hudson server running OpenBSD/x86, that was >>> easy, not configured yet (still cross building cm3 and will try a >>> Tinderbox run first instead.) >>> >>> LINUXLIBC6 is yellow, but this looks ok: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >>> >>> Do they have to be more recent? Or need last release and last ok? >>> I only do last ok. You don't have last release for AMD64_LINUX, it >>> doesn't exist, but are green. >>> Maybe two separate builds are needed? >>> >>> SPARC32_LINUX is yellow but it also looks ok. >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 >> >> Tinderbox shows running builds that haven't complete yet in yellow. >> Results are either green, red, or orange. So the result transfer to >> the server may have failed. >> >>> The most recent completed PPC_LINUX failed to get much of the >>> source tree in the CVS checkout. That happens often. I should >>> probably put in a retry or something.. >> >> No. You should probably do something about your network connection ;-) >> >> BTW, the exit you put in after the cvs checkout won't work this way. >> Unless you use special bash pipe result evaluation, it's always the >> _last_ process in a pipe that determines its result code. >> >>> (Bringing back I386_DARWIN, funny thing there, is that to compile >>> X client, you need Python, and the in-box one isn't new enough, >>> and current doesn't build out of the box because it assumes a full >>> Mac system..still working on it..) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ >> any >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be >> rlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> From hosking at cs.purdue.edu Sun Jul 26 20:00:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:00:14 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <200907261557.n6QFvTIu008442@niagara.cs.purdue.edu> Message-ID: I haven't digested this closely, but here is the latest niagara tinderbox log with +x. Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: July 26, 2009 11:57:29 AM EDT > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > + trap cleanup 1 2 3 6 > + [ -z cm3.build ] > + . cm3.build > PROJECT=cm3 > TREENAME=cm3 > BUILD_REL=rel > BUILD_REL_NAME=rel > REGRESSION_SCRIPTS_DIR=regression-scripts > + [ rel = rel ] > BUILD_REL_NAME=release > + hostname > + [ -f ~/cm3/niagara.cs.purdue.edu.conf ] > CVSROOT=:ext:modula3.elegosoft.com:/usr/cvs > + cvs -d :ext:modula3.elegosoft.com:/usr/cvs checkout -A -d > regression-scripts cm3/scripts/regression/defs.sh > U regression-scripts/defs.sh > + test -r regression-scripts/defs.sh > + . regression-scripts/defs.sh > + sed -e s/\..*//+ hostname > > TESTHOSTNAME=niagara > HTMP=/homes/hosking/tmp/cm3/niagara > + tr -d+ date\n -u > +%Y-%m-%d-%H-%M-%S > DS=2009-07-26-10-30-05 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > COVERSION=-P -r release_branch_cm3_5_8 > LASTREL=5.4.0 > INSTBASE=/homes/hosking/work/cm3-inst/niagara > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + test x != x > CM3CVSUSER_AT= > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > WWWSERVER=birch.elegosoft.com > RLOG=/homes/hosking/tmp/cm3/niagara/cm3-rlog-2009-07-26-10-30-05 > CM3_NKEEP=7 > + uname > UNAME=SunOS > + uname -m > UNAMEM=sun4v > TMP=/tmp > TMPDIR=/tmp > + [ ! -d /tmp ] > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > M3TOUT=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-10-30-05.stdout > M3TERR=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-10-30-05.stderr > CM3_VERSION=* > CM3_SNAPSHOT=/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu- > *-2009-07-26-10-30-05.tgz > HTML_REPORT=/tmp/cm3-pkg-report-SOLgnu-2009-07-26-10-30-05.html > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_LOC=/homes/hosking/work > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_URL=http://modula3.elegosoft.com/cm3 > + echo TESTHOSTNAME=niagara > TESTHOSTNAME=niagara > + echo WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > + echo LASTREL=5.4.0 > LASTREL=5.4.0 > + echo INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > + echo INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > + echo INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > + echo INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + echo CM3_OSTYPE=POSIX > CM3_OSTYPE=POSIX > + echo CM3_TARGET=SOLgnu > CM3_TARGET=SOLgnu > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSSERVER=birch.elegosoft.com > CM3CVSSERVER=birch.elegosoft.com > + echo CM3CVSROOT=birch.elegosoft.com:/usr/cvs > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > + echo BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSUSER= > CM3CVSUSER= > + type cvs > + true > + echo testing ssh birch.elegosoft.com.. > testing ssh birch.elegosoft.com.. > + ssh birch.elegosoft.com true > + echo ssh birch.elegosoft.com ok > ssh birch.elegosoft.com ok > + true > + [ ! -d /homes/hosking/tmp/cm3/niagara ] > + uname -s > + uname -r > TESTMACHINE=SunOS 5.10 > TTT=SOLgnu SunOS 5.10 niagara > BUILDNAME=SOLgnu SunOS 5.10 niagara release-build > + [ -z cm3 -o -z cm3 ] > BUILDNAME=SOLgnu SunOS 5.10 niagara release-build > + echo Building cm3. > Building cm3. > + echo Tinderbox Tree: "cm3" > Tinderbox Tree: "cm3" > + echo Buildname: "SOLgnu SunOS 5.10 niagara release-build" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > + echo > > + date +%Y%m%d-%H%M%S > NAME=build-cm3-20090726-063007 > + date +%s > STARTTIME=1248604207 > BUILDDIR_ROOT=/tmp > + mktemp -d /tmp/build-cm3-20090726-063007-XXXXXX > BUILDDIR_BASE=/tmp/build-cm3-20090726-063007-yIa4JX > BUILDDIR=/tmp/build-cm3-20090726-063007-yIa4JX/build > LOG=/tmp/build-cm3-20090726-063007-yIa4JX/log.txt > T=/tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + mkdir /tmp/build-cm3-20090726-063007-yIa4JX/build > + [ ! -d /tmp/build-cm3-20090726-063007-yIa4JX/build ] > + echo creating log file /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > creating log file /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + touch /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + [ ! -w /tmp/build-cm3-20090726-063007-yIa4JX/log.txt ] > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo > > + echo --- > --- > + echo > > + echo checkout, compile and test of cm3 ... > checkout, compile and test of cm3 ... > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 06:30:07 -- checkout in progress. > 2009.07.26 06:30:07 -- checkout in progress. > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248604207 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [start checkout 2009.07.26 06:30:09] > [start checkout 2009.07.26 06:30:09] > + echo cd /tmp/build-cm3-20090726-063007-yIa4JX/build > cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + do_checkout > CHECKOUT_RETURN=0 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo cvs return value: 0 > + date +%Y.%m.%d %H:%M:%S > cvs return value: 0 > + echo [end checkout 2009.07.26 06:45:02] > [end checkout 2009.07.26 06:45:02] > + echo CHECKOUT_RETURN = 0 > CHECKOUT_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248605102 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo -- > -- > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 06:45:12 -- compile in progress. > 2009.07.26 06:45:12 -- compile in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start compile 2009.07.26 06:45:12] > [start compile 2009.07.26 06:45:12] > + do_compile > COMPILE_RETURN=0 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo compile return value: 0 > compile return value: 0 > + date +%Y.%m.%d %H:%M:%S > + echo [end compile 2009.07.26 08:24:29] > [end compile 2009.07.26 08:24:29] > + echo COMPILE_RETURN = 0 > COMPILE_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248611069 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 08:24:34 -- tests in progress. > 2009.07.26 08:24:34 -- tests in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start run-tests 2009.07.26 08:24:34] > [start run-tests 2009.07.26 08:24:34] > + echo cd /tmp/build-cm3-20090726-063007-yIa4JX/build > cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + do_tests > TESTS_RETURN=511 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [end run-tests 2009.07.26 10:39:00] > [end run-tests 2009.07.26 10:39:00] > + echo TESTS_RETURN = 511 > TESTS_RETURN = 511 > + [ 511 != 0 ] > + + echotee *** TESTS FAILED-a > /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > *** TESTS FAILED > + mail_buildlog test_failed > + [ -z test_failed ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > test_failed 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=test_failed > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > test_failed -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248619141 > + echo tinderbox: status: test_failed > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + + catssh /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temptinderbox.elego.de > sudo -u tinderbox /usr/local/tinderbox/tinderbox-cgi/ > processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + cleanup > + echo removing build tree /tmp/build-cm3-20090726-063007-yIa4JX ... > removing build tree /tmp/build-cm3-20090726-063007-yIa4JX ... > + cd /tmp > + rm -rf /tmp/build-cm3-20090726-063007-yIa4JX > + do_cleanup > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > + exit 1 > + trap cleanup 1 2 3 6 > + [ -z cm3.build ] > + . cm3.build > PROJECT=cm3 > TREENAME=cm3 > BUILD_REL=lastok > BUILD_REL_NAME=lastok > REGRESSION_SCRIPTS_DIR=regression-scripts > + [ lastok = rel ] > + hostname > + [ -f ~/cm3/niagara.cs.purdue.edu.conf ] > CVSROOT=:ext:modula3.elegosoft.com:/usr/cvs > + cvs -d :ext:modula3.elegosoft.com:/usr/cvs checkout -A -d > regression-scripts cm3/scripts/regression/defs.sh > + test -r regression-scripts/defs.sh > + . regression-scripts/defs.sh > + sed -e s/\..*// > + hostname > TESTHOSTNAME=niagara > HTMP=/homes/hosking/tmp/cm3/niagara > + tr+ date-d -u\n +%Y-%m-%d-%H-%M-%S > > DS=2009-07-26-14-41-31 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > COVERSION=-P -r release_branch_cm3_5_8 > LASTREL=5.4.0 > INSTBASE=/homes/hosking/work/cm3-inst/niagara > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + test x != x > CM3CVSUSER_AT= > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > WWWSERVER=birch.elegosoft.com > RLOG=/homes/hosking/tmp/cm3/niagara/cm3-rlog-2009-07-26-14-41-31 > CM3_NKEEP=7 > + uname > UNAME=SunOS > + uname -m > UNAMEM=sun4v > TMP=/tmp > TMPDIR=/tmp > + [ ! -d /tmp ] > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > M3TOUT=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-14-41-31.stdout > M3TERR=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-14-41-31.stderr > CM3_VERSION=* > CM3_SNAPSHOT=/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu- > *-2009-07-26-14-41-31.tgz > HTML_REPORT=/tmp/cm3-pkg-report-SOLgnu-2009-07-26-14-41-31.html > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_LOC=/homes/hosking/work > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_URL=http://modula3.elegosoft.com/cm3 > + echo TESTHOSTNAME=niagara > TESTHOSTNAME=niagara > + echo WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > + echo LASTREL=5.4.0 > LASTREL=5.4.0 > + echo INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > + echo INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > + echo INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > + echo INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + echo CM3_OSTYPE=POSIX > CM3_OSTYPE=POSIX > + echo CM3_TARGET=SOLgnu > CM3_TARGET=SOLgnu > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSSERVER=birch.elegosoft.com > CM3CVSSERVER=birch.elegosoft.com > + echo CM3CVSROOT=birch.elegosoft.com:/usr/cvs > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > + echo BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSUSER= > CM3CVSUSER= > + type cvs > + true > + echo testing ssh birch.elegosoft.com.. > testing ssh birch.elegosoft.com.. > + ssh birch.elegosoft.com true > + echo ssh birch.elegosoft.com ok > ssh birch.elegosoft.com ok > + true > + [ ! -d /homes/hosking/tmp/cm3/niagara ] > + uname -s > + uname -r > TESTMACHINE=SunOS 5.10 > TTT=SOLgnu SunOS 5.10 niagara > BUILDNAME=SOLgnu SunOS 5.10 niagara lastok-build > + [ -z cm3 -o -z cm3 ] > BUILDNAME=SOLgnu SunOS 5.10 niagara lastok-build > + echo Building cm3. > Building cm3. > + echo Tinderbox Tree: "cm3" > Tinderbox Tree: "cm3" > + echo Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > + echo > > + date +%Y%m%d-%H%M%S > NAME=build-cm3-20090726-104133 > + date +%s > STARTTIME=1248619293 > BUILDDIR_ROOT=/tmp > + mktemp -d /tmp/build-cm3-20090726-104133-XXXXXX > BUILDDIR_BASE=/tmp/build-cm3-20090726-104133-R0aGhi > BUILDDIR=/tmp/build-cm3-20090726-104133-R0aGhi/build > LOG=/tmp/build-cm3-20090726-104133-R0aGhi/log.txt > T=/tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + mkdir /tmp/build-cm3-20090726-104133-R0aGhi/build > + [ ! -d /tmp/build-cm3-20090726-104133-R0aGhi/build ] > + echo creating log file /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > creating log file /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + touch /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + [ ! -w /tmp/build-cm3-20090726-104133-R0aGhi/log.txt ] > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo > > + echo --- > --- > + echo > > + echo checkout, compile and test of cm3 ... > checkout, compile and test of cm3 ... > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 10:41:34 -- checkout in progress. > 2009.07.26 10:41:34 -- checkout in progress. > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248619294 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [start checkout 2009.07.26 10:41:36] > [start checkout 2009.07.26 10:41:36] > + echo cd /tmp/build-cm3-20090726-104133-R0aGhi/build > cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + do_checkout > CHECKOUT_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a + /tmp/build-cm3-20090726-104133-R0aGhi/log.txtecho > cvs return value: 0 > + date +%Y.%m.%d %H:%M:%S > cvs return value: 0 > + echo [end checkout 2009.07.26 10:56:34] > [end checkout 2009.07.26 10:56:34] > + echo CHECKOUT_RETURN = 0 > CHECKOUT_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248620194 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp+ ssh > tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo -- > -- > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 10:56:36 -- compile in progress. > 2009.07.26 10:56:36 -- compile in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start compile 2009.07.26 10:56:36] > [start compile 2009.07.26 10:56:36] > + do_compile > COMPILE_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo compile return value: 0 > compile return value: 0 > + date +%Y.%m.%d %H:%M:%S > + echo [end compile 2009.07.26 11:54:10] > [end compile 2009.07.26 11:54:10] > + echo COMPILE_RETURN = 0 > COMPILE_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248623650 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp+ ssh > tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 11:54:14 -- tests in progress. > 2009.07.26 11:54:14 -- tests in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start run-tests 2009.07.26 11:54:14] > [start run-tests 2009.07.26 11:54:14] > + echo cd /tmp/build-cm3-20090726-104133-R0aGhi/build > cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + do_tests > TESTS_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [end run-tests 2009.07.26 11:54:14] > [end run-tests 2009.07.26 11:54:14] > + echo TESTS_RETURN = 0 > TESTS_RETURN = 0 > + [ 0 != 0 ] > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 11:54:14 -- checkout, compile and test run done. > 2009.07.26 11:54:14 -- checkout, compile and test run done. > + echo > > + echo --- > --- > + echo > > + mail_buildlog success > + [ -z success ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > success 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=success > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > success -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248623654 > + echo tinderbox: status: success > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp + > ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + cleanup > + echo removing build tree /tmp/build-cm3-20090726-104133-R0aGhi ... > removing build tree /tmp/build-cm3-20090726-104133-R0aGhi ... > + cd /tmp > + rm -rf /tmp/build-cm3-20090726-104133-R0aGhi > + do_cleanup > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > + echo done. > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 26 20:03:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:03:30 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> Message-ID: The error is coming from the server. Nothing in the CVS tree validates timenow or prints this error. # function used to send results to a tinderbox server. # per default it is empty so the build-log will just be output to stdout. tinderbox_mailer() { true # needed if function is empty without this... # to report to the elego tinderbox host, check README and uncomment this: #cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox \ #/usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" } It is that /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi. Whether you/we started feeding it different data somehow I don't know. However I don't have GNU date so I made it work with whatever is the Solaris default. I'm inclined to move on, but I agree it is not understood. Maybe put in which date type data before the runs? - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 13:48:35 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > I have not changed my tinderbox install on niagara for over a year and > it suddenly stopped working so the problem must be with some recent > commit. Note that I installed the GNU binutils way back when (over a > year ago) so that things would work with 'date +%s'. > > Sent from my iPhone > > On Jul 26, 2009, at 6:07 AM, Jay K wrote: > >> >> I'm running Tinderbox on SOLgnu now. >> It fails with that error without a change and gets past the first >> email if I change the date commands. >> The first cvs checkout eventually failed, trying again.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>> Date: Sun, 26 Jul 2009 03:09:59 +0000 >>> >>> >>> Tony reverted it. I'm bringing my Solaris/sparc machine up to date >>> and will try running Tinderbox. >>> I will likely try with plain date and see what happens there and >>> otherwise. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 25 Jul 2009 22:00:15 +0200 >>>> From: wagner at elegosoft.com >>>> To: hosking at cs.purdue.edu >>>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> Quoting Tony Hosking : >>>> >>>>> I've not changed anything on my side. >>>> >>>> I don't understand why I missed that: >>>> >>>> revision 1.13 >>>> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >>>> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >>>> let's just try plain date, based on the choices in the error message >>>> ---------------------------- >>>> >>>> But you seem to have fixed it already: >>>> >>>> revision 1.14 >>>> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >>>> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >>>> Revert to what used to work. >>>> >>>> Strange that it didn't show up in my first diff. >>>> >>>> Olaf >>>> >>>> >>>>> >>>>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>>>> >>>>>> I don't see how that will help us... It worked for Tony for over >>>>>> a year, and nothing obvious has changed. Or did something change >>>>>> on >>>>>> your side, Tony (system upgrade, path setting, ...)? >>>>>> >>>>>> It's not good to introduce arbitrary changes now without >>>>>> understanding >>>>>> why it breaks. >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting Jay K : >>>>>> >>>>>>> >>>>>>> Can I suggest the portable scripting language C? >>>>>>> >>>>>>> >>>>>>> -bash-3.00$ cat date.c >>>>>>> #include >>>>>>> #include >>>>>>> #include >>>>>>> int main() >>>>>>> { >>>>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>>>> return 0; >>>>>>> } >>>>>>> -bash-3.00$ cc date.c -o ./mydate >>>>>>> -bash-3.00$ ./mydate >>>>>>> 1248549753 >>>>>>> -bash-3.00$ pwd >>>>>>> /dev2/cm3/scripts >>>>>>> >>>>>>> >>>>>>> use that instead? >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>> >>>>>>>> >>>>>>>> (two occurences of that) >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>>>> >>>>>>>>> >>>>>>>>> This line: >>>>>>>>> >>>>>>>>> >>>>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>>>> >>>>>>>>> needs to more like these lines: >>>>>>>>> >>>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>>>> >>>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>>>> run done." >>>>>>>>> >>>>>>>>> >>>>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>>>> 2009.07.25 12:13:54 >>>>>>>>> >>>>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>>>> 07.25.09 12:14:33 >>>>>>>>> >>>>>>>>> -bash-3.00$ date +%s >>>>>>>>> %s >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>>>> From: wagner at elegosoft.com >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>>>> >>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>> >>>>>>>>>>> Perhaps I am confusing with the original change I made for >>>>>>>>>>> 1.10 to the >>>>>>>>>>> parameter to the "date" command. >>>>>>>>>>> >>>>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>>>> properly. It's been a long time since I've seen a sane >>>>>>>>>>> tinderbox run >>>>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>>>> >>>>>>>>>> I broke the last one yesterday with $() (fixed soon >>>>>>>>>> afterwards), but >>>>>>>>>> the one before succeeded: >>>>>>>>>> >>>>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>>>> >>>>>>>>>> I was hoping to get a green build from one of your systems >>>>>>>>>> today >>>>>>>>>> (big-endian, different architecture) to finally fix the RC2 >>>>>>>>>> tag. >>>>>>>>>> But if you cannot send your results to the tinderbox that >>>>>>>>>> will be >>>>>>>>>> difficult :-/ I really don't understand why that should have >>>>>>>>>> stopped >>>>>>>>>> working. >>>>>>>>>> >>>>>>>>>> The error below seems to be that the reported start time is >>>>>>>>>> 0, and >>>>>>>>>> that cannot be according to the source. Could you set -x at >>>>>>>>>> the start >>>>>>>>>> of the tinderbox script and try again? >>>>>>>>>> >>>>>>>>>> Jay, can you think of anything you have changed that may >>>>>>>>>> cause Tony's >>>>>>>>>> problem? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>>> -- Tony (not mobile) >>>>>>>>>> :-) >>>>>>>>>> >>>>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>>>> >>>>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>>>> >>>>>>>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>>>>>>> ago. Can >>>>>>>>>>>>> someone restore? >>>>>>>>>>>> >>>>>>>>>>>> Hi Tony, >>>>>>>>>>>> >>>>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>>> *************** >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>>>> date 'date +%s'" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: >>>>>>>>>>>> $STARTTIME >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>>>> >>>>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>>>> >>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>> Jul-09 >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>>> *************** >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>>>> *************** >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did >>>>>>>>>>>> you change >>>>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>> >>>>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>>>> >>>>>>>>>>>>>> produced the following output: >>>>>>>>>>>>>> >>>>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>>>> >>>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>>>>>>> log.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: >>>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>>> clock >>>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>>>>>>> minutes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023- >>>>>>>>>>>>>> tVaq2V ... >>>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>>> *.tgz >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>>>> >>>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>>>>>>> log.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: >>>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>>> clock >>>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032- >>>>>>>>>>>>>> xba4dW ... >>>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>>> *.tgz >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>>>> 45 86 95 >>>>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>>>> Sitz: Berlin >>>>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>>>> IdNr: >>>>>>>>>>>> DE163214194 >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>>> 23 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wag >>>>>>>>>> ner | Sitz: Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>> IdNr: DE163214194 >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Si >>>>>> tz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> From jay.krell at cornell.edu Sun Jul 26 20:07:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:07:54 +0000 Subject: [M3devel] OpenGL on Darwin 10.4 x86 (not MacOSX)? Message-ID: Anyone gotten OpenGL working in Darwin 10.4 x86? I don't mean MacOSX. The stripped down Darwin thing. I had a heck of a time getting X libraries on the machine. I had to upgrade Python. And X has been broken into a bunch of separate pieces. And Xaw installs kind of wrong -- Xaw7.dylib, Xaw6.dylib, and Xaw.so -- .so! I changed it around to look like my PPC_LINUX machine to get past that.. Anyway, I have libGL but not some others..tried building Mesa and SGI glx. I think I'll give up. Make the system check for SYSTEM_LIBS/LIBORDER, skip packages, and not build distributions on this system. Or am I missing smoething?? I did search the web some. Haven't asked the X/Mesa people. Maybe Fink is the way? But the result won't by default be compatible with Mac OSX. - Jay From hosking at cs.purdue.edu Sun Jul 26 20:13:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:13:09 -0400 Subject: [M3devel] libz in Tinderbox? In-Reply-To: References: Message-ID: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> What needs libz? I think it is already installed but will need to log on when able to to find where it is installed. Sent from my iPhone On Jul 26, 2009, at 1:16 PM, Jay K wrote: > > Tony can you install libz? Or should we import it? Or should we > maybe probe for $HOME/lib/libz.a or somewhere else? > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 > > "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- > tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake > runtime error: file libz.a not found in /usr/lib /usr/local/lib / > lib /usr/contrib/lib /opt/lib > 22072 > > > There is also: > > Must be attached to terminal for ?am I? option > 49575 + [ niagara = birch.elegosoft.com -a = m3 ] > 49576 ./tinderbox-build.sh: test: argument expected > 49577 r4=1 > 49578 + expr 0 + 0 + 255 + 255 + 1 > 49579 + return 511 > 49580 + date +%Y.%m.%d %H:%M:%S > 49581 + echo [end run-tests 2009.07.26 10:39:00] > 49582 [end run-tests 2009.07.26 10:39:00] > 49583 *** TESTS FAILED > > > - Jay From jay.krell at cornell.edu Sun Jul 26 20:28:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:28:06 +0000 Subject: [M3devel] libz in Tinderbox? In-Reply-To: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> References: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> Message-ID: cvsup. >> "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- >> tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 14:13:09 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] libz in Tinderbox? > > What needs libz? I think it is already installed but will need to log > on when able to to find where it is installed. > > Sent from my iPhone > > On Jul 26, 2009, at 1:16 PM, Jay K wrote: > >> >> Tony can you install libz? Or should we import it? Or should we >> maybe probe for $HOME/lib/libz.a or somewhere else? >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 >> >> "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- >> tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake >> runtime error: file libz.a not found in /usr/lib /usr/local/lib / >> lib /usr/contrib/lib /opt/lib >> 22072 >> >> >> There is also: >> >> Must be attached to terminal for ?am I? option >> 49575 + [ niagara = birch.elegosoft.com -a = m3 ] >> 49576 ./tinderbox-build.sh: test: argument expected >> 49577 r4=1 >> 49578 + expr 0 + 0 + 255 + 255 + 1 >> 49579 + return 511 >> 49580 + date +%Y.%m.%d %H:%M:%S >> 49581 + echo [end run-tests 2009.07.26 10:39:00] >> 49582 [end run-tests 2009.07.26 10:39:00] >> 49583 *** TESTS FAILED >> >> >> - Jay From jay.krell at cornell.edu Sun Jul 26 20:29:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:29:57 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: I can try that. It is a null pointer though I believe. interesting..?? On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, showthread all fail to come up. showheap comes up but doesn't show anything. I've tried some of these in the past and they worked better, though I didn't use them for anything. Maybe just a slow machine? And I'm too impatient? Yes, but I don't think that's the problem. xterm comes right up. As does the empty showheap window. Could be a wierd X server too, granted (Xming). I can try Cygwin/X and I was thinking of buying a commercial one (just for this few minutes of testing per month..) If I don't set DISPLAY ..most still hang, except showthread. Specifically showthread fails, but the others still seem to hang. $ unset DISPLAY $ ./showthread *** *** runtime error: *** Exception "TrestleComm.Failure" not in RAISES list *** file "../src/vbt/TrestleClass.m3", line 33 *** Abort trap (core dumped) I'm not sure that's how it should fail, but failure is expected. I think I've seen the failure mode vary too, but again, failure is expected there. So like we aren't even getting to XOpenDisplay. Hey, not much to debug.. perhaps.. Here is Cube hung. Again this is OpenBSD, not the most mature platform from the Modula-3 point of view. Though imho the platforms are all highly similar. $ gdb ./Cube GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.5"... (gdb) run Starting program: /home/jay/cm3/bin/Cube ? Program received signal SIGINT, Interrupt. -- I hit control-c --- 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) info threads 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched (scp=Cannot access memory at address 0x37b3 ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 (gdb) thread 5 bt A syntax error in expression, near `bt'. (gdb) thread 5 apply bt A syntax error in expression, near `apply bt'. (gdb) thread apply 5 bt Thread 5 (process 3778, thread 0x84901400): #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 Cannot access memory at address 0x37ab #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 4 bt Thread 4 (process 3778, thread 0x84901000): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x849010b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, mutex=0x8afb09e0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) at ../src/vbt/VBTRep.m3:439 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591380) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 3 bt Thread 3 (process 3778, thread 0x8182e800): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182e8b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, mutex=0x20e900dc, abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431 #3 0x00e955a7 in _thread_gc (arg=0x0) at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 #4 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #5 0x0000002b in ?? () #6 0x00000000 in ?? () #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 2 bt Thread 2 (process 3778, thread 0x8182ec00): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182ecb0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, mutex=0x8afb0a50) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) at ../src/vtext/VTView.m3:111 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591980) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 1 bt Thread 1 (process 3778, thread 0x8182e400): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182e4b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, mutex=0x8afb0b20) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) at ../src/lego/FileBrowserVBT.m3:241 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591500) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 0 bt warning: Unknown thread 0. (gdb) I should debug this more but not now. And we should be sure to try these on other platforms, see if the hangs occur. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 13:57:07 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Stack overflow? > > And yes, I have seen deep recursions like that. What happens if you > use a deeper stack? > > Sent from my iPhone > > On Jul 26, 2009, at 8:48 AM, Jay K wrote: > >> >> Ok here is the formsedit crash. >> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >> PPC_LINUX. >> I can try those again. >> >> >> It doesn't happen every time, but some large fraction, like maybe >> half. >> I changed the SIGsEGV to an assertion failure. >> >> >> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >> -bash-3.00$ ./formsedit >> >> *** >> *** runtime error: >> *** failed. >> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >> *** >> Abort (core dumped) >> >> You can't debug it live because you keep getting interrupted by sig >> usr2. >> >> -bash-3.00$ dbx formsedit core >> >> t at 1 (l at 1) terminated by signal KILL (Killed) >> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >> 0xfe3c00a4 >> >> These statements from the debugger about main/AddUnit don't make >> sense to me. >> >> Current function is main >> 13 RTLinker__AddUnit (FormsEdit_M3); >> >> (dbx) where >> current thread: t at 1 >> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 >> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xfe4680b8 >> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >> 0xfe467ca0 >> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >> 0xfefa5adc >> >> Does the code really recurse like this? >> >> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >> 0xffbf9ca0, 0xfe4a5d >> 00, 0xfef48180), at 0xfef48520 >> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >> 0xff000000, 0x0, 0x0 >> ), at 0xff046ea4 >> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >> 0xffbf9e48, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >> 0xffbf9f18, 0 >> x0, 0xff0437d8), at 0xff043864 >> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >> 0xffbfa0a8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >> 0xffbfa238, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >> 0xffbfa3c8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >> 0xffbfa558, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >> 0xffbfa6e8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >> 0xffbfa878, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >> 0xffbfaa08, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >> 0xffbfab98, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >> 0xffbfad28, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >> 0xffbfaeb8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >> 0xffbfb048, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >> 0xffbfb1d8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >> 0xffbfb368, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >> 0xffbfb4f8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >> 0xffbfb688, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >> 0xffbfb818, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >> 0xffbfb9a8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >> 0xffbfbb38, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >> 0xffbfbcc8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >> 0xffbfbe58, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >> 0xffbfbfe8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >> 0xffbfc178, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >> 0xffbfc308, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >> 0xffbfc498, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >> 0xfe1b2000, 0x6b170 >> , 0x0), at 0xff046ea4 >> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >> 0xff000000, >> 0x0, 0x0), at 0xff191d20 >> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b27 >> 0, 0x0), at 0xfefb6a38 >> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >> 0xfe1b2000, >> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b290, 0x0), at 0xfefbc9f4 >> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b2b >> 0, 0x0), at 0xfefb6a38 >> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >> 0xfe1b2000, >> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b2d0, 0x0), at 0xfefbc9f4 >> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6af7 >> 0, 0x0), at 0xfefb6a38 >> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >> 0xff000000, >> 0x0, 0x0), at 0xfefbc9f4 >> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b33 >> 0, 0x0), at 0xfefb6a38 >> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b698, 0x0), at 0xfefbc9f4 >> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >> 0xfe1b2000, 0x6b69 >> 8, 0x0), at 0xfefbc9f4 >> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >> 0xfe1b2000, 0xf >> e4a5d00, 0x0), at 0xfefeb348 >> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b6b8, 0x0), at 0xfefbc9f4 >> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b7f >> 8, 0x0), at 0xfefb6a38 >> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b858, 0x0), at 0xfefbc9f4 >> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >> 0x0, 0x0), at >> 0xfefb6a38 >> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b858, 0x0), at 0xfefbc9f4 >> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >> 0xff000000, 0x0 >> , 0x0), at 0xff18d2ec >> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b87 >> 8, 0x0), at 0xfefb6a38 >> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b898, 0x0), at 0xfefbc9f4 >> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >> 0xfe1b2000, 0x6b89 >> 8, 0x0), at 0xfefbc9f4 >> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >> 0xfe1b2000, 0x6 >> b8b8, 0x0), at 0xfefeb348 >> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >> 0x20, 0xffbfd >> b20), at 0xfefb6a38 >> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >> 0xfe1b2000, >> 0x6b8b8, 0x0), at 0xfefbc9f4 >> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xff01f884 >> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b8d8, 0x0), at 0xfefbc9f4 >> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xff19e338 >> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x60338, 0x0), at 0xfefbc9f4 >> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4a5d >> 00, 0x0), at 0xfeff6db4 >> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >> 0xfe1b2000 >> , 0x6e5a0, 0x0), at 0xfefbc9f4 >> (dbx) >> (dbx) threads >>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >> ___nanosleep >> () >> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >> in __lwp_pa >> rk() >> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >> ___nanosleep >> () >> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >> in __lwp_pa >> rk() >> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >> in __lwp_pa >> rk() >> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >> in __lwp_pa >> rk() >> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >> __lwp_kill( >> ) >> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >> in __lwp_pa >> rk() >> (dbx) >> >> >> The crashing thread: >> >> (dbx) thread t at 27 >> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >> 0xfe3c11f4 >> (dbx) where >> current thread: t at 27 >> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >> 0xfe35fdd8 >> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >> 0xfe33fff8 >> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >> 0xfe46255c >> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >> 0xfe4529c8 >> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >> 0xfddf0900), at 0x >> fe44f2e4 >> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >> 0xfe4b4d90, 0xff2 >> 50434), at 0xfe44ee5c >> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >> 0x100000), >> at 0xfe44fa0c >> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >> ), >> at 0xfe44f590 >> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >> 0xfffffff8, 0x0, >> 0xfdc53131), at 0xfe44f44c >> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >> 0x0), at 0xfe46 >> 470c >> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >> ), >> at 0xfe44f680 >> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >> 0xfffffff8, 0x0, >> 0xfdc53661), at 0xfe44f44c >> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >> 0x0, 0xfdc538 >> e1), at 0xfe46470c >> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >> 0xfdc53a40, 0xfdc539 >> 2c, 0xfdc53928), at 0xfe42ffe0 >> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >> 0xfdc53a40), a >> t 0xff141d64 >> >> (too many frames for an assertion failure imho!) >> >> >> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >> 0x1000, 0x0, >> 0x0), at 0xff13dda4 >> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >> 0xff000000, 0x0, >> 0x0), at 0xff13d9e8 >> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >> 0xfddf0800, >> 0x69da0, 0x0), at 0xff140730 >> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >> 0xff000000, 0xff00000 >> 0, 0x0, 0x1), at 0xff1407d0 >> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >> 0xfdd221bc), a >> t 0xfefb8f04 >> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >> 0xfefc5170 >> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >> 0xfddf0800, 0x90 >> 410, 0x0), at 0xfefc45a8 >> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >> 0xfefc4674 >> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >> 0xfe46bc00 >> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >> 0xfe46b740, 0x1) >> , at 0xfe46b790 >> (dbx) >> >> >> - Jay From hosking at cs.purdue.edu Sun Jul 26 20:34:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:34:02 -0400 Subject: [M3devel] libz in Tinderbox? In-Reply-To: References: Message-ID: Looks like we have it in /opt/csw/lib/ Sent from my iPhone On Jul 26, 2009, at 1:16 PM, Jay K wrote: > > Tony can you install libz? Or should we import it? Or should we > maybe probe for $HOME/lib/libz.a or somewhere else? > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 > > "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- > tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake > runtime error: file libz.a not found in /usr/lib /usr/local/lib / > lib /usr/contrib/lib /opt/lib > 22072 > > > There is also: > > Must be attached to terminal for ?am I? option > 49575 + [ niagara = birch.elegosoft.com -a = m3 ] > 49576 ./tinderbox-build.sh: test: argument expected > 49577 r4=1 > 49578 + expr 0 + 0 + 255 + 255 + 1 > 49579 + return 511 > 49580 + date +%Y.%m.%d %H:%M:%S > 49581 + echo [end run-tests 2009.07.26 10:39:00] > 49582 [end run-tests 2009.07.26 10:39:00] > 49583 *** TESTS FAILED > > > - Jay From hosking at cs.purdue.edu Sun Jul 26 20:40:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:40:57 -0400 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> Message-ID: <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> Why are we building the X client libs? Xcode should install them? Sent from my iPhone On Jul 26, 2009, at 1:57 PM, Jay K wrote: > From jay.krell at cornell.edu Sun Jul 26 20:46:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:46:04 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> Message-ID: This is just me trying to get my x86 Darwin 10.4 system able to build the Modula-3 gui stuff. Not MacOSX, but Darwin. I don't believe you can do anything at with Xcode on this. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 14:40:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Tinderbox/Hudson > > Why are we building the X client libs? > Xcode should install them? > > Sent from my iPhone > > On Jul 26, 2009, at 1:57 PM, Jay K wrote: > >> From jay.krell at cornell.edu Sun Jul 26 22:43:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 20:43:03 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: Larger stack didn't seem to help. I used export STACKSIZE=32768 and ulimit shownew/showthread come up ok on this platform, OpenBSD/x86 doesn't represent all of them. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] the formsedit crash > Date: Sun, 26 Jul 2009 18:29:57 +0000 > > > I can try that. > > > It is a null pointer though I believe. > > > interesting..?? > > > On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, showthread all fail to come up. > showheap comes up but doesn't show anything. > I've tried some of these in the past and they worked better, though I didn't use them for anything. > > > Maybe just a slow machine? > And I'm too impatient? Yes, but I don't think that's the problem. > > > xterm comes right up. > As does the empty showheap window. > > > Could be a wierd X server too, granted (Xming). > I can try Cygwin/X and I was thinking of buying a commercial one (just for > this few minutes of testing per month..) > > > If I don't set DISPLAY ..most still hang, except showthread. > Specifically showthread fails, but the others still seem to hang. > > > $ unset DISPLAY > $ ./showthread > > *** > *** runtime error: > *** Exception "TrestleComm.Failure" not in RAISES list > *** file "../src/vbt/TrestleClass.m3", line 33 > *** > Abort trap (core dumped) > > > I'm not sure that's how it should fail, but failure is expected. > I think I've seen the failure mode vary too, but again, failure is expected there. > > > So like we aren't even getting to XOpenDisplay. > Hey, not much to debug.. perhaps.. > > > Here is Cube hung. > Again this is OpenBSD, not the most mature platform from the Modula-3 point of view. > Though imho the platforms are all highly similar. > > > $ gdb ./Cube > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) run > Starting program: /home/jay/cm3/bin/Cube > ? > Program received signal SIGINT, Interrupt. -- I hit control-c --- > 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) info threads > 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched (scp=Cannot > access memory at address 0x37b3 > ) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 > 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > (gdb) thread 5 bt > A syntax error in expression, near `bt'. > (gdb) thread 5 apply bt > A syntax error in expression, near `apply bt'. > (gdb) thread apply 5 bt > Thread 5 (process 3778, thread 0x84901400): > #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 > ) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 > Cannot access memory at address 0x37ab > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 4 bt > Thread 4 (process 3778, thread 0x84901000): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x849010b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, mutex=0x8afb09e0) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, > M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, > M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) > at ../src/vbt/VBTRep.m3:439 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591380) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 3 bt > Thread 3 (process 3778, thread 0x8182e800): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182e8b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, mutex=0x20e900dc, > abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431 > #3 0x00e955a7 in _thread_gc (arg=0x0) > at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 > #4 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #5 0x0000002b in ?? () > #6 0x00000000 in ?? () > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 2 bt > Thread 2 (process 3778, thread 0x8182ec00): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182ecb0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, mutex=0x8afb0a50) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, > M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, > M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) > at ../src/vtext/VTView.m3:111 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591980) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 1 bt > Thread 1 (process 3778, thread 0x8182e400): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182e4b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, mutex=0x8afb0b20) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, > M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, > M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) > at ../src/lego/FileBrowserVBT.m3:241 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591500) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 0 bt > warning: Unknown thread 0. > (gdb) > > I should debug this more but not now. > And we should be sure to try these on other platforms, see if the hangs occur. > > - Jay > > > > > > > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 26 Jul 2009 13:57:07 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> Stack overflow? >> >> And yes, I have seen deep recursions like that. What happens if you >> use a deeper stack? >> >> Sent from my iPhone >> >> On Jul 26, 2009, at 8:48 AM, Jay K wrote: >> >>> >>> Ok here is the formsedit crash. >>> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >>> PPC_LINUX. >>> I can try those again. >>> >>> >>> It doesn't happen every time, but some large fraction, like maybe >>> half. >>> I changed the SIGsEGV to an assertion failure. >>> >>> >>> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >>> -bash-3.00$ ./formsedit >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >>> *** >>> Abort (core dumped) >>> >>> You can't debug it live because you keep getting interrupted by sig >>> usr2. >>> >>> -bash-3.00$ dbx formsedit core >>> >>> t at 1 (l at 1) terminated by signal KILL (Killed) >>> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >>> 0xfe3c00a4 >>> >>> These statements from the debugger about main/AddUnit don't make >>> sense to me. >>> >>> Current function is main >>> 13 RTLinker__AddUnit (FormsEdit_M3); >>> >>> (dbx) where >>> current thread: t at 1 >>> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >>> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 >>> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xfe4680b8 >>> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>> 0xfe467ca0 >>> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>> 0xfefa5adc >>> >>> Does the code really recurse like this? >>> >>> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >>> 0xffbf9ca0, 0xfe4a5d >>> 00, 0xfef48180), at 0xfef48520 >>> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >>> 0xff000000, 0x0, 0x0 >>> ), at 0xff046ea4 >>> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >>> 0xffbf9e48, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >>> 0xffbf9f18, 0 >>> x0, 0xff0437d8), at 0xff043864 >>> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >>> 0xffbfa0a8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >>> 0xffbfa238, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >>> 0xffbfa3c8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >>> 0xffbfa558, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >>> 0xffbfa6e8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >>> 0xffbfa878, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >>> 0xffbfaa08, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >>> 0xffbfab98, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >>> 0xffbfad28, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >>> 0xffbfaeb8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >>> 0xffbfb048, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >>> 0xffbfb1d8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >>> 0xffbfb368, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >>> 0xffbfb4f8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >>> 0xffbfb688, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >>> 0xffbfb818, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >>> 0xffbfb9a8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >>> 0xffbfbb38, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >>> 0xffbfbcc8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >>> 0xffbfbe58, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >>> 0xffbfbfe8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >>> 0xffbfc178, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >>> 0xffbfc308, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >>> 0xffbfc498, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >>> 0xfe1b2000, 0x6b170 >>> , 0x0), at 0xff046ea4 >>> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >>> 0xff000000, >>> 0x0, 0x0), at 0xff191d20 >>> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b27 >>> 0, 0x0), at 0xfefb6a38 >>> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b290, 0x0), at 0xfefbc9f4 >>> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b2b >>> 0, 0x0), at 0xfefb6a38 >>> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b2d0, 0x0), at 0xfefbc9f4 >>> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6af7 >>> 0, 0x0), at 0xfefb6a38 >>> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >>> 0xff000000, >>> 0x0, 0x0), at 0xfefbc9f4 >>> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b33 >>> 0, 0x0), at 0xfefb6a38 >>> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b698, 0x0), at 0xfefbc9f4 >>> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >>> 0xfe1b2000, 0x6b69 >>> 8, 0x0), at 0xfefbc9f4 >>> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >>> 0xfe1b2000, 0xf >>> e4a5d00, 0x0), at 0xfefeb348 >>> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b6b8, 0x0), at 0xfefbc9f4 >>> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b7f >>> 8, 0x0), at 0xfefb6a38 >>> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b858, 0x0), at 0xfefbc9f4 >>> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >>> 0x0, 0x0), at >>> 0xfefb6a38 >>> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b858, 0x0), at 0xfefbc9f4 >>> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >>> 0xff000000, 0x0 >>> , 0x0), at 0xff18d2ec >>> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b87 >>> 8, 0x0), at 0xfefb6a38 >>> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b898, 0x0), at 0xfefbc9f4 >>> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >>> 0xfe1b2000, 0x6b89 >>> 8, 0x0), at 0xfefbc9f4 >>> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6 >>> b8b8, 0x0), at 0xfefeb348 >>> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >>> 0x20, 0xffbfd >>> b20), at 0xfefb6a38 >>> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >>> 0xfe1b2000, >>> 0x6b8b8, 0x0), at 0xfefbc9f4 >>> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xff01f884 >>> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b8d8, 0x0), at 0xfefbc9f4 >>> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xff19e338 >>> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x60338, 0x0), at 0xfefbc9f4 >>> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4a5d >>> 00, 0x0), at 0xfeff6db4 >>> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >>> 0xfe1b2000 >>> , 0x6e5a0, 0x0), at 0xfefbc9f4 >>> (dbx) >>> (dbx) threads >>>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >>> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >>> ___nanosleep >>> () >>> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >>> in __lwp_pa >>> rk() >>> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >>> ___nanosleep >>> () >>> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >>> in __lwp_pa >>> rk() >>> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >>> in __lwp_pa >>> rk() >>> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >>> in __lwp_pa >>> rk() >>> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >>> __lwp_kill( >>> ) >>> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >>> in __lwp_pa >>> rk() >>> (dbx) >>> >>> >>> The crashing thread: >>> >>> (dbx) thread t at 27 >>> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >>> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >>> 0xfe3c11f4 >>> (dbx) where >>> current thread: t at 27 >>> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >>> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >>> 0xfe35fdd8 >>> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >>> 0xfe33fff8 >>> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >>> 0xfe46255c >>> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >>> 0xfe4529c8 >>> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >>> 0xfddf0900), at 0x >>> fe44f2e4 >>> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >>> 0xfe4b4d90, 0xff2 >>> 50434), at 0xfe44ee5c >>> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >>> 0x100000), >>> at 0xfe44fa0c >>> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >>> ), >>> at 0xfe44f590 >>> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>> 0xfffffff8, 0x0, >>> 0xfdc53131), at 0xfe44f44c >>> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >>> 0x0), at 0xfe46 >>> 470c >>> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >>> ), >>> at 0xfe44f680 >>> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>> 0xfffffff8, 0x0, >>> 0xfdc53661), at 0xfe44f44c >>> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >>> 0x0, 0xfdc538 >>> e1), at 0xfe46470c >>> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >>> 0xfdc53a40, 0xfdc539 >>> 2c, 0xfdc53928), at 0xfe42ffe0 >>> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >>> 0xfdc53a40), a >>> t 0xff141d64 >>> >>> (too many frames for an assertion failure imho!) >>> >>> >>> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >>> 0x1000, 0x0, >>> 0x0), at 0xff13dda4 >>> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >>> 0xff000000, 0x0, >>> 0x0), at 0xff13d9e8 >>> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >>> 0xfddf0800, >>> 0x69da0, 0x0), at 0xff140730 >>> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >>> 0xff000000, 0xff00000 >>> 0, 0x0, 0x1), at 0xff1407d0 >>> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >>> 0xfdd221bc), a >>> t 0xfefb8f04 >>> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >>> 0xfefc5170 >>> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >>> 0xfddf0800, 0x90 >>> 410, 0x0), at 0xfefc45a8 >>> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >>> 0xfefc4674 >>> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >>> 0xfe46bc00 >>> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >>> 0xfe46b740, 0x1) >>> , at 0xfe46b790 >>> (dbx) >>> >>> >>> - Jay From wagner at elegosoft.com Sun Jul 26 23:09:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 23:09:45 +0200 Subject: [M3devel] Late news Message-ID: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> Hi again, I just browsed through the latest messages... I can barely keep up with reading everything. Tinderbox results look much better now, almost nothing is red any more. Can you make sure that you're building the branch during release engineering and not from the trunk? I think you are, if you are using the latest defs.sh and not a customized one. Solaris seems to be OK again, after the confusion of yesterday evening. I was not really aware that Tinderbox depends on a GNU date option though. We should add I386_DARWIN to the list of required platform, too, as Tony mentioned. Thanks that you're looking into the formsedit crash now. I guess I was getting a bit impatient this morning :-/ I shouldn't have taken over release engineering if I am though :-) As for setting up Hudson for release engineering: if anyone gives me remote ssh access with a separate account (preferably hudson), enough disk space and CPU power (and JDK >= 1.5), I can set up a slave server for birch remotely without any problems. I've done that several times now. It's just an offer for those who may have idling machines standing in the attic though ;-) I assume it should even work on Windows. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 00:22:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 00:22:58 +0200 Subject: [M3devel] gcc error on PPC_DARWIN Message-ID: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> compiler bootstrap on PPC_DARWIN failed with `invalid option 32': http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console Do we really require 64-bit capable tools now on all systems? Or did I make some stupid error again? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 06:09:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 04:09:02 +0000 Subject: [M3devel] gcc error on PPC_DARWIN In-Reply-To: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> References: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> Message-ID: I kind of throw in that everywhere until/unless shown that it hurts and isn't needed. Indeed it doesn't always work, not always on gcc, not always on cm3cg. I have this probe in Darwin.common now, since I was using an AMD64_DARWIN machine the other day: if not defined("SYSTEM_CC") not this part if equal(WORD_SIZE, "32BITS") SYSTEM_CC = "32" else SYSTEM_CC = "64" end % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -fPIC -m" & SYSTEM_CC local a = SYSTEM_CC & " -arch " & GccArch this part, with -arch or not local b = try_exec("@" & a & " -v 2>/dev/null") if equal(b, 0) SYSTEM_CC = a end %write("SYSTEM_CC is " & SYSTEM_CC & "\n") end if not defined("SYSTEM_LIBTOOL") readonly SYSTEM_LIBTOOL = "libtool" end which should be redundant with the -m32/64 stuff, so try just: if not defined("SYSTEM_CC") % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -fPIC" local a = SYSTEM_CC & " -arch " & GccArch local b = try_exec("@" & a & " -v 2>/dev/null") if equal(b, 0) SYSTEM_CC = a end %write("SYSTEM_CC is " & SYSTEM_CC & "\n") end if not defined("SYSTEM_LIBTOOL") readonly SYSTEM_LIBTOOL = "libtool" end I know this kind of probing is inefficient -- we do it every invocation of cm3. We could at least limit it to if there is a need to compile C or link -- like how GetM3BackFlags works now (sort of -- not probe related, but just related to bootstrapping or not). The alternative is to let users edit or have cminstall do the probe -- and have it go stale when the tools change.. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 00:22:58 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] gcc error on PPC_DARWIN > > compiler bootstrap on PPC_DARWIN failed with `invalid option 32': > http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console > > Do we really require 64-bit capable tools now on all systems? > Or did I make some stupid error again? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 06:16:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 04:16:15 +0000 Subject: [M3devel] crash in m3bundle on SPARC64_OPENBSD Message-ID: == package /dev2/cm3/m3-sys/cm3ide == +++ /cm3/bin/cm3 -build -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSI ON_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in SPARC64_OPENBSD --- ignoring ../src/m3overrides /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x134afc = NoteStackLocations + 0x2c in ../src/runtime/common/RTColl ector.m3 *** Abort trap (core dumped) new source -> compiling Buf.i3 $ cd /dev2/cm3/m3-sys/cm3ide $ rm -rf SPARC64_OPENBSD/ $ /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x134afc = NoteStackLocations + 0x2c in ../src/runtime/common/RTColl ector.m3 *** Abort trap (core dumped) $ gdb --args /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-openbsd4.3"... (gdb) run Starting program: /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk Program received signal SIGSEGV, Segmentation fault. 0x0000000000134afc in RTCollector__NoteStackLocations ( M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) at ../src/runtime/common/RTCollector.m3:525 525 WITH page = AddressToPage(fp^) DO (gdb) disas Dump of assembler code for function RTCollector__NoteStackLocations: 0x0000000000134ad0 : save %sp, -224, %sp 0x0000000000134ad4 : stx %i0, [ %fp + 0x87f ] 0x0000000000134ad8 : stx %i1, [ %fp + 0x887 ] 0x0000000000134adc : ldx [ %fp + 0x8 7f ], %g1 0x0000000000134ae0 : stx %g1, [ %fp + 0x7df ] 0x0000000000134ae4 : ldx [ %fp + 0x8 87 ], %g1 0x0000000000134ae8 : add %g1, -8, %g 1 0x0000000000134aec : stx %g1, [ %fp + 0x887 ] 0x0000000000134af0 : b %xcc, 0x134ba c 0x0000000000134af4 : nop 0x0000000000134af8 : ldx [ %fp + 0x7 df ], %g1 0x0000000000134afc : ldx [ %g1 ], %g <<< here 1 0x0000000000134b00 : mov %g1, %o0 ---Type to continue, or q to quit---q Quit (gdb) p $g1 $1 = 0 <<< null deref (gdb) bt #0 0x0000000000134afc in RTCollector__NoteStackLocations ( M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) at ../src/runtime/common/RTCollector.m3:525 #1 0x000000000015a44c in ThreadPThread__ProcessMe ( M3_CgoaiZ_me=0xd800000000000000, M3_Ad3xEV_p=0x58daebea047a3667) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #2 0x0000000000159e48 in ThreadF__ProcessStacks ( M3_Ad3xEV_p=0x10000000004d8c29) at ../src/thread/PTHREAD/ThreadPThread.m3:938 #3 0x000000000013680c in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:821 #4 0x0000000000135ee4 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:721 #5 0x0000000000135600 in RTCollector__CollectEnough ( M3_AicXUJ_allocator=56 '8') at ../src/runtime/common/RTCollector.m3:653 #6 0x000000000013986c in RTCollector__LongAlloc ( M3_Cwb5VA_dataSize=11889503016258108627, M3_Cwb5VA_dataAlignment=12754194144713243859, M3_D000bG_pool=0xc300000000000000) at ../src/runtime/common/RTCollector.m3:1438 #7 0x0000000000139644 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=0, M3_Cwb5VA_dataAlignment=0, M3_D000bG_pool=0x0) at ../src/runtime/common/RTCollector.m3:1400 #8 0x0000000000130578 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) ---Type to continue, or q to quit--- at ../src/runtime/common/RTAllocator.m3:222 #9 0x000000000012fc50 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:120 #10 0x0000000000156c8c in ThreadPThread__CreateT (M3_CgoaiZ_act=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:497 #11 0x000000000015bb5c in ThreadF__Init () at ../src/thread/PTHREAD/ThreadPThread.m3:1377 #12 0x000000000014392c in RTLinker__InitRuntime ( M3_AcxOUs_p_argc=7455543629306877523, M3_AJWxb1_p_argv=0x5f5253483d737368, M3_AJWxb1_p_envp=0x5353485f545459, M3_AJWxb1_p_instance=0x3d2f6465762f7474) at ../src/runtime/common/RTLinker.m3:59 #13 0x00000000001028e4 in main (argc=0, argv=0x0, envp=0x0) at _m3main.mc:3 It happens every time. wild guess would be that..SPARC platforms without stack walker don't work? No, SPARC32_LINUX does better. That no SPARC64 platform works? Could be. We'll see in SPARC64_SOLARIS, SPARC64_LINUX /eventually/. I'll try to let this go for now, it being SPARC64_OPENBSD.. This is also two releases behind. $ uname -a OpenBSD jay-sun2.jkhome 4.3 GENERIC#1555 sparc64 current OpenBSD release is 4.5. - Jay From jay.krell at cornell.edu Mon Jul 27 09:12:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 07:12:52 +0000 Subject: [M3devel] Late news In-Reply-To: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> References: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> Message-ID: As for setting up Hudson for release engineering: if anyone gives meremote ssh access with a separate account (preferably hudson), - Can you checkin text files to configure it? - Do you have the thing setup where it submits reports? Ie: where the master doesn't need access to the slave, or such? - All my machines are behind NAT. I think I could give you access one at a time via forwarding port 22?, and actually, I only have the server running so far on NT and one other machine. I wasn't able to get a public key from ~wagner/.ssh or ~hudson/.ssh on birch, access denied ok..I think I have something, separate mail.. - Jay ---------------------------------------- > Date: Sun, 26 Jul 2009 23:09:45 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Late news > > Hi again, > > I just browsed through the latest messages... I can barely keep up > with reading everything. > > Tinderbox results look much better now, almost nothing is red any more. > Can you make sure that you're building the branch during release > engineering and not from the trunk? I think you are, if you are using > the latest defs.sh and not a customized one. > > Solaris seems to be OK again, after the confusion of yesterday evening. > I was not really aware that Tinderbox depends on a GNU date option > though. > > We should add I386_DARWIN to the list of required platform, too, > as Tony mentioned. > > Thanks that you're looking into the formsedit crash now. > I guess I was getting a bit impatient this morning :-/ > I shouldn't have taken over release engineering if I am though :-) > > As for setting up Hudson for release engineering: if anyone gives me > remote ssh access with a separate account (preferably hudson), > enough disk space and CPU power (and JDK>= 1.5), I can set up a > slave server for birch remotely without any problems. I've done > that several times now. > It's just an offer for those who may have idling machines standing in > the attic though ;-) I assume it should even work on Windows. > > So long, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 11:16:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 09:16:48 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: >>> I've heard cvs is a cpu hog, it's one reason people switch away from >>> it (which I hope we'll do after this release..) > > > I'll have to search, initial searches failed. > > >> Not that I know... it usually sleeps while waiting for file i/o. > > > True. Load average is high on birch, 8. I don't know what this means but I thought it was was supposed to be around 1. Or is 1 times the number of processors? cvs, by me and hudson, often visible taking a lot, judging by top. Tinderbox...is causing too much heat in my apartment. After a few green runs I'll have to see about powering the machines on once a week or something for one run and then power back off. Maybe leave just one running daily or in a loop, like LINUXLIB6. Later maybe move all x86/amd64 machines to virtual machines and inherit power management of host or scheduled power off/on. - Jay From jay.krell at cornell.edu Mon Jul 27 13:28:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 11:28:54 +0000 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) Message-ID: CVS checkout and update of an entire tree seem to be extremely unreliable. It takes a while and often times out. I don't have time to do this right now, I think the cvs update/checkout should go like this: if directory doesn't exist: checkout with -l if directory does exist (it always will now actually, this if can go, except to error if it doesn't exist) cd into it upd -l various hardcoded directories, m3-sys scripts m3-ui m3-libs www doc This list need not be complete and it may contain directories that don't exist. for each directory cvs -z3 upd -dAP that directory notice that after the first one, the directory list will be correct Possibly do it like m3-sys m3-sys/m3cc m3-sys/m3gdb m3-libs m3-libs/m3core m3-libs/libm3 to breakdown some of the larger ones. and then one cvs -z3 upd -dAP at the root check return code of just that line one, if failed, wait five minutes try again, if failed, fail I plan to implement this and I'd /prefer/ to use Python. If nobody else wants it, I'll turn it off by default. Even just leaving the workspace aorund doesn't seem to solve the problem. I'd also be curious about -z1 vs. -z3. I usually use -z3. That's what some documentation recommended. - Jay From wagner at elegosoft.com Mon Jul 27 14:30:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 14:30:39 +0200 Subject: [M3devel] crash in m3bundle on SPARC64_OPENBSD In-Reply-To: References: Message-ID: <20090727143039.fp8eyulhb4ggcgkc@mail.elegosoft.com> Please put the evidence into a trac ticket. Thanks, Olaf Quoting Jay K : > > == package /dev2/cm3/m3-sys/cm3ide == > > +++ /cm3/bin/cm3 -build -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 > -DCM3_VERSI > ON_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in SPARC64_OPENBSD --- > ignoring ../src/m3overrides > /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x134afc = NoteStackLocations + 0x2c in > ../src/runtime/common/RTColl > ector.m3 > *** > Abort trap (core dumped) > new source -> compiling Buf.i3 > > $ cd /dev2/cm3/m3-sys/cm3ide > $ rm -rf SPARC64_OPENBSD/ > $ /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x134afc = NoteStackLocations + 0x2c in > ../src/runtime/common/RTColl > ector.m3 > *** > Abort trap (core dumped) > > $ gdb --args /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc64-unknown-openbsd4.3"... > (gdb) run > Starting program: /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000134afc in RTCollector__NoteStackLocations ( > M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) > at ../src/runtime/common/RTCollector.m3:525 > 525 WITH page = AddressToPage(fp^) DO > (gdb) disas > Dump of assembler code for function RTCollector__NoteStackLocations: > 0x0000000000134ad0 : save %sp, -224, %sp > 0x0000000000134ad4 : stx %i0, [ %fp + 0x87f > ] > 0x0000000000134ad8 : stx %i1, [ %fp + 0x887 > ] > 0x0000000000134adc : ldx [ %fp + 0x8 > 7f ], %g1 > 0x0000000000134ae0 : stx %g1, [ %fp > + 0x7df ] > 0x0000000000134ae4 : ldx [ %fp + 0x8 > 87 ], %g1 > 0x0000000000134ae8 : add %g1, -8, %g > 1 > 0x0000000000134aec : stx %g1, [ %fp > + 0x887 ] > 0x0000000000134af0 : b %xcc, 0x134ba > c > 0x0000000000134af4 : nop > 0x0000000000134af8 : ldx [ %fp + 0x7 > df ], %g1 > 0x0000000000134afc : ldx [ %g1 ], %g <<< here > 1 > 0x0000000000134b00 : mov %g1, %o0 > ---Type to continue, or q to quit---q > Quit > (gdb) p $g1 > $1 = 0 <<< null deref > (gdb) bt > #0 0x0000000000134afc in RTCollector__NoteStackLocations ( > M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) > at ../src/runtime/common/RTCollector.m3:525 > #1 0x000000000015a44c in ThreadPThread__ProcessMe ( > M3_CgoaiZ_me=0xd800000000000000, M3_Ad3xEV_p=0x58daebea047a3667) > at ../src/thread/PTHREAD/ThreadPThread.m3:1014 > #2 0x0000000000159e48 in ThreadF__ProcessStacks ( > M3_Ad3xEV_p=0x10000000004d8c29) > at ../src/thread/PTHREAD/ThreadPThread.m3:938 > #3 0x000000000013680c in RTCollector__CollectSomeInStateZero () > at ../src/runtime/common/RTCollector.m3:821 > #4 0x0000000000135ee4 in RTCollector__CollectSome () > at ../src/runtime/common/RTCollector.m3:721 > #5 0x0000000000135600 in RTCollector__CollectEnough ( > M3_AicXUJ_allocator=56 '8') at ../src/runtime/common/RTCollector.m3:653 > #6 0x000000000013986c in RTCollector__LongAlloc ( > M3_Cwb5VA_dataSize=11889503016258108627, > M3_Cwb5VA_dataAlignment=12754194144713243859, > M3_D000bG_pool=0xc300000000000000) > at ../src/runtime/common/RTCollector.m3:1438 > #7 0x0000000000139644 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=0, > M3_Cwb5VA_dataAlignment=0, M3_D000bG_pool=0x0) > at ../src/runtime/common/RTCollector.m3:1400 > #8 0x0000000000130578 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) > ---Type to continue, or q to quit--- > at ../src/runtime/common/RTAllocator.m3:222 > #9 0x000000000012fc50 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) > at ../src/runtime/common/RTAllocator.m3:120 > #10 0x0000000000156c8c in ThreadPThread__CreateT (M3_CgoaiZ_act=0x0) > at ../src/thread/PTHREAD/ThreadPThread.m3:497 > #11 0x000000000015bb5c in ThreadF__Init () > at ../src/thread/PTHREAD/ThreadPThread.m3:1377 > #12 0x000000000014392c in RTLinker__InitRuntime ( > M3_AcxOUs_p_argc=7455543629306877523, > M3_AJWxb1_p_argv=0x5f5253483d737368, M3_AJWxb1_p_envp=0x5353485f545459, > M3_AJWxb1_p_instance=0x3d2f6465762f7474) > at ../src/runtime/common/RTLinker.m3:59 > #13 0x00000000001028e4 in main (argc=0, argv=0x0, envp=0x0) at _m3main.mc:3 > > > It happens every time. > > > wild guess would be that..SPARC platforms without stack walker don't work? > No, SPARC32_LINUX does better. > > > That no SPARC64 platform works? Could be. > We'll see in SPARC64_SOLARIS, SPARC64_LINUX /eventually/. > > > I'll try to let this go for now, it being SPARC64_OPENBSD.. > > > This is also two releases behind. > > > $ uname -a > OpenBSD jay-sun2.jkhome 4.3 GENERIC#1555 sparc64 > > > current OpenBSD release is 4.5. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 15:19:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 15:19:56 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> Quoting Jay K : >>>> I've heard cvs is a cpu hog, it's one reason people switch away from >>>> it (which I hope we'll do after this release..) >> >> I'll have to search, initial searches failed. >> >>> Not that I know... it usually sleeps while waiting for file i/o. >> >> True. > > Load average is high on birch, 8. > I don't know what this means but I thought it was was supposed to be > around 1. No. The load average is the average number of processes competing for cpu within the last one/five/fifteen minutes. See http://en.wikipedia.org/wiki/Load_(computing) for details. In general no process will wait for CPU at all if your load average is lower than the number of processors. > Or is 1 times the number of processors? o Linux systems count not only runnable processes as the article in Wikipedia says. o Unix systems in general can handle high loads fairly well. o birch is performing a lot of services: CVS, ssh, ftp, web service, trac, mail backup, etc. So a somewhat higher load is expected. > cvs, by me and hudson, often visible taking a lot, judging by top. I really think the limiting factor are the disks, unless you are using compression and/or encryption (-z, ssh access). But that is not inherent to CVS. You will find that running other SCM systems (like ClearCase, Subversion with HTTPS/Apache access, PVCS/Dimensions, ...) will put much higher demands to your resources than simple CVS. > Tinderbox...is causing too much heat in my apartment. After a few > green runs I'll have to see about powering the machines on once a > week or something for one run and then power back off. That's understandable. > Maybe leave just one running daily or in a loop, like LINUXLIB6. > Later maybe move all x86/amd64 machines to virtual machines and > inherit power management of host or scheduled power off/on. I think we should try to obtain access to a few machines in a large data center. Perhaps we can use the HP Partner Virtualization Program. I'm not sure if we can get access for an open source project or need to make a contract as a company (Elego). We'll investigate that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 15:31:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 15:31:55 +0200 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) Message-ID: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> Quoting Jay K : > CVS checkout and update of an entire tree seem to be extremely unreliable. > It takes a while and often times out. It should not take longer than about 5 minutes, and considering the number of files and amount of data to be transferred, that's quite acceptable. > I don't have time to do this right now, I think the cvs > update/checkout should go like this: > > if directory doesn't exist: > checkout with -l > > if directory does exist (it always will now actually, this if can > go, except to error if it doesn't exist) > cd into it > upd -l various hardcoded directories, m3-sys scripts m3-ui m3-libs www doc > This list need not be complete and it may contain directories > that don't exist. > for each directory cvs -z3 upd -dAP that directory > notice that after the first one, the directory list will be correct > Possibly do it like m3-sys m3-sys/m3cc m3-sys/m3gdb m3-libs > m3-libs/m3core m3-libs/libm3 > to breakdown some of the larger ones. > and then one cvs -z3 upd -dAP at the root > check return code of just that line one, if failed, wait five > minutes try again, if failed, fail > > I plan to implement this and I'd /prefer/ to use Python. > > If nobody else wants it, I'll turn it off by default. > > Even just leaving the workspace aorund doesn't seem to solve the problem. I don't think it's a good idea. If you really want to speed it up and make it more robust, replicate the CM3 repo locally and do checkouts via the file system (much faster without ssh). You may run cvsup in a loop to get all changes quickly. If we really run out of resources on birch, we may need to set up a public r/o copy of the repository for cvs access. > I'd also be curious about -z1 vs. -z3. > I usually use -z3. That's what some documentation recommended. I think it may rather make performance worse as compression needs much CPU on birch, which may not be available under high system loads. Please remember that birch is used for other purposes by Elego than only to serve the CM3 repository. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 15:53:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 13:53:09 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> Message-ID: I am using ssh, and just -z1. 5 minutes I don't think so. It takes quite a while..maybe a minute, on a cvs -z3 upd from the root before it transfers any files. But subsequent nearby-in-time runs are faster. Some caching affects but they are surprising -- which cache? How much data is being accessed? I don't know, haven't traced it or anything. Yeah some source control is heavyweight but I think many are not. Git seems to be rapidly gaining in popularity and with that you probably hit "the server" much less. I worry "distributed source control" like Git would make sharing changes too infrequent, maybe worse than the other side too requent. I thought cvsup might be a good solution but haven't tried it yet. Only time/interest for so many new things at a time. I'll check with a friend about hosting my weirdo machines. I see the Mac has good command line control of "scheduled wake". If all my hardware had "scheduled wake" would be easy. I only first saw this feature recently on an SGI. I don't know how common it is. Ultimately an Intel Mac with scheduled sleep/wake, and starting up N virtual machines upon startup, either on a schedule or that each wait an hour, two hours, three hours, etc. before doing anything, should be able to substitute for I figure roughly 15 machines -- (Linux + OpenBSD + FreeBSD + NetBSD + Solaris + NT + Darwin) * (I386 + AMD4) + PPC_DARWIN. I had an Intel Mac but returned it and will get a "bigger" (more diskspace) soon. Heck, just run them all serially in a loop, just one heat spewing machine, should be a good setup. And then gradually try to add even more esoteric systems (Spin?). It kind of feels like cheating but also seems like a good idea. VMware has even automated the installs of some operating systems, very nice. Still that leaves PPC, SPARC, MIPS, IA64, Alpha to run on real hardware (though several of those boast virtualization features, I expect it is much harder to get up and running than the x86 virtualization products..) - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 15:19:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] tinderbox status improvements/diagnosis > > Quoting Jay K : > >>>>> I've heard cvs is a cpu hog, it's one reason people switch away from >>>>> it (which I hope we'll do after this release..) >>> >>> I'll have to search, initial searches failed. >>> >>>> Not that I know... it usually sleeps while waiting for file i/o. >>> >>> True. >> >> Load average is high on birch, 8. >> I don't know what this means but I thought it was was supposed to be >> around 1. > > No. The load average is the average number of processes competing for cpu > within the last one/five/fifteen minutes. See > http://en.wikipedia.org/wiki/Load_(computing) for details. > > In general no process will wait for CPU at all if your load average > is lower than the number of processors. > >> Or is 1 times the number of processors? > > o Linux systems count not only runnable processes as the article > in Wikipedia says. > > o Unix systems in general can handle high loads fairly well. > > o birch is performing a lot of services: CVS, ssh, ftp, web service, > trac, mail backup, etc. So a somewhat higher load is expected. > >> cvs, by me and hudson, often visible taking a lot, judging by top. > > I really think the limiting factor are the disks, unless you are > using compression and/or encryption (-z, ssh access). But that is > not inherent to CVS. > > You will find that running other SCM systems (like ClearCase, > Subversion with HTTPS/Apache access, PVCS/Dimensions, ...) will > put much higher demands to your resources than simple CVS. > >> Tinderbox...is causing too much heat in my apartment. After a few >> green runs I'll have to see about powering the machines on once a >> week or something for one run and then power back off. > > That's understandable. > >> Maybe leave just one running daily or in a loop, like LINUXLIB6. > >> Later maybe move all x86/amd64 machines to virtual machines and >> inherit power management of host or scheduled power off/on. > > I think we should try to obtain access to a few machines in a > large data center. Perhaps we can use the HP Partner Virtualization Program. > I'm not sure if we can get access for an open source project or need > to make a contract as a company (Elego). We'll investigate that. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hosking at cs.purdue.edu Mon Jul 27 15:52:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Jul 2009 09:52:46 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: Not sure if doing it that way works. Current default stack size set in ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try changing it there. On 26 Jul 2009, at 16:43, Jay K wrote: > > Larger stack didn't seem to help. > > I used export STACKSIZE=32768 > and ulimit > > shownew/showthread come up ok on this platform, OpenBSD/x86 doesn't > represent all of them. > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] the formsedit crash >> Date: Sun, 26 Jul 2009 18:29:57 +0000 >> >> >> I can try that. >> >> >> It is a null pointer though I believe. >> >> >> interesting..?? >> >> >> On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, >> showthread all fail to come up. >> showheap comes up but doesn't show anything. >> I've tried some of these in the past and they worked better, though >> I didn't use them for anything. >> >> >> Maybe just a slow machine? >> And I'm too impatient? Yes, but I don't think that's the problem. >> >> >> xterm comes right up. >> As does the empty showheap window. >> >> >> Could be a wierd X server too, granted (Xming). >> I can try Cygwin/X and I was thinking of buying a commercial one >> (just for >> this few minutes of testing per month..) >> >> >> If I don't set DISPLAY ..most still hang, except showthread. >> Specifically showthread fails, but the others still seem to hang. >> >> >> $ unset DISPLAY >> $ ./showthread >> >> *** >> *** runtime error: >> *** Exception "TrestleComm.Failure" not in RAISES list >> *** file "../src/vbt/TrestleClass.m3", line 33 >> *** >> Abort trap (core dumped) >> >> >> I'm not sure that's how it should fail, but failure is expected. >> I think I've seen the failure mode vary too, but again, failure is >> expected there. >> >> >> So like we aren't even getting to XOpenDisplay. >> Hey, not much to debug.. perhaps.. >> >> >> Here is Cube hung. >> Again this is OpenBSD, not the most mature platform from the >> Modula-3 point of view. >> Though imho the platforms are all highly similar. >> >> >> $ gdb ./Cube >> GNU gdb 6.3 >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) run >> Starting program: /home/jay/cm3/bin/Cube >> ? >> Program received signal SIGINT, Interrupt. -- I hit control-c --- >> 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) info threads >> 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched >> (scp=Cannot >> access memory at address 0x37b3 >> ) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 >> 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> (gdb) thread 5 bt >> A syntax error in expression, near `bt'. >> (gdb) thread 5 apply bt >> A syntax error in expression, near `apply bt'. >> (gdb) thread apply 5 bt >> Thread 5 (process 3778, thread 0x84901400): >> #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 >> ) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 >> Cannot access memory at address 0x37ab >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 4 bt >> Thread 4 (process 3778, thread 0x84901000): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x849010b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, >> mutex=0x8afb09e0) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, >> M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, >> M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) >> at ../src/vbt/VBTRep.m3:439 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591380) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 3 bt >> Thread 3 (process 3778, thread 0x8182e800): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182e8b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, >> mutex=0x20e900dc, >> abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/ >> uthread_cond.c:431 >> #3 0x00e955a7 in _thread_gc (arg=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 >> #4 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #5 0x0000002b in ?? () >> #6 0x00000000 in ?? () >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 2 bt >> Thread 2 (process 3778, thread 0x8182ec00): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182ecb0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, >> mutex=0x8afb0a50) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, >> M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, >> M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) >> at ../src/vtext/VTView.m3:111 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591980) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 1 bt >> Thread 1 (process 3778, thread 0x8182e400): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182e4b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, >> mutex=0x8afb0b20) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, >> M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, >> M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) >> at ../src/lego/FileBrowserVBT.m3:241 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591500) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 0 bt >> warning: Unknown thread 0. >> (gdb) >> >> I should debug this more but not now. >> And we should be sure to try these on other platforms, see if the >> hangs occur. >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 26 Jul 2009 13:57:07 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] the formsedit crash >>> >>> Stack overflow? >>> >>> And yes, I have seen deep recursions like that. What happens if you >>> use a deeper stack? >>> >>> Sent from my iPhone >>> >>> On Jul 26, 2009, at 8:48 AM, Jay K wrote: >>> >>>> >>>> Ok here is the formsedit crash. >>>> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >>>> PPC_LINUX. >>>> I can try those again. >>>> >>>> >>>> It doesn't happen every time, but some large fraction, like maybe >>>> half. >>>> I changed the SIGsEGV to an assertion failure. >>>> >>>> >>>> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >>>> -bash-3.00$ ./formsedit >>>> >>>> *** >>>> *** runtime error: >>>> *** failed. >>>> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >>>> *** >>>> Abort (core dumped) >>>> >>>> You can't debug it live because you keep getting interrupted by sig >>>> usr2. >>>> >>>> -bash-3.00$ dbx formsedit core >>>> >>>> t at 1 (l at 1) terminated by signal KILL (Killed) >>>> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >>>> 0xfe3c00a4 >>>> >>>> These statements from the debugger about main/AddUnit don't make >>>> sense to me. >>>> >>>> Current function is main >>>> 13 RTLinker__AddUnit (FormsEdit_M3); >>>> >>>> (dbx) where >>>> current thread: t at 1 >>>> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >>>> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at >>>> 0xfe3b85e4 >>>> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xfe4680b8 >>>> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>>> 0xfe467ca0 >>>> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>>> 0xfefa5adc >>>> >>>> Does the code really recurse like this? >>>> >>>> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >>>> 0xffbf9ca0, 0xfe4a5d >>>> 00, 0xfef48180), at 0xfef48520 >>>> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >>>> 0xff000000, 0x0, 0x0 >>>> ), at 0xff046ea4 >>>> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >>>> 0xffbf9e48, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >>>> 0xffbf9f18, 0 >>>> x0, 0xff0437d8), at 0xff043864 >>>> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >>>> 0xffbfa0a8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >>>> 0xffbfa238, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >>>> 0xffbfa3c8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >>>> 0xffbfa558, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >>>> 0xffbfa6e8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >>>> 0xffbfa878, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >>>> 0xffbfaa08, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >>>> 0xffbfab98, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >>>> 0xffbfad28, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >>>> 0xffbfaeb8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >>>> 0xffbfb048, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >>>> 0xffbfb1d8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >>>> 0xffbfb368, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >>>> 0xffbfb4f8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >>>> 0xffbfb688, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >>>> 0xffbfb818, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >>>> 0xffbfb9a8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >>>> 0xffbfbb38, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >>>> 0xffbfbcc8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >>>> 0xffbfbe58, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >>>> 0xffbfbfe8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >>>> 0xffbfc178, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >>>> 0xffbfc308, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >>>> 0xffbfc498, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >>>> 0xfe1b2000, 0x6b170 >>>> , 0x0), at 0xff046ea4 >>>> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >>>> 0xff000000, >>>> 0x0, 0x0), at 0xff191d20 >>>> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b27 >>>> 0, 0x0), at 0xfefb6a38 >>>> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>>> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b290, 0x0), at 0xfefbc9f4 >>>> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b2b >>>> 0, 0x0), at 0xfefb6a38 >>>> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>>> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b2d0, 0x0), at 0xfefbc9f4 >>>> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6af7 >>>> 0, 0x0), at 0xfefb6a38 >>>> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >>>> 0xff000000, >>>> 0x0, 0x0), at 0xfefbc9f4 >>>> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b33 >>>> 0, 0x0), at 0xfefb6a38 >>>> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b698, 0x0), at 0xfefbc9f4 >>>> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >>>> 0xfe1b2000, 0x6b69 >>>> 8, 0x0), at 0xfefbc9f4 >>>> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xf >>>> e4a5d00, 0x0), at 0xfefeb348 >>>> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b6b8, 0x0), at 0xfefbc9f4 >>>> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b7f >>>> 8, 0x0), at 0xfefb6a38 >>>> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b858, 0x0), at 0xfefbc9f4 >>>> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >>>> 0x0, 0x0), at >>>> 0xfefb6a38 >>>> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b858, 0x0), at 0xfefbc9f4 >>>> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >>>> 0xff000000, 0x0 >>>> , 0x0), at 0xff18d2ec >>>> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b87 >>>> 8, 0x0), at 0xfefb6a38 >>>> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b898, 0x0), at 0xfefbc9f4 >>>> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >>>> 0xfe1b2000, 0x6b89 >>>> 8, 0x0), at 0xfefbc9f4 >>>> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6 >>>> b8b8, 0x0), at 0xfefeb348 >>>> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >>>> 0x20, 0xffbfd >>>> b20), at 0xfefb6a38 >>>> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >>>> 0xfe1b2000, >>>> 0x6b8b8, 0x0), at 0xfefbc9f4 >>>> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xff01f884 >>>> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b8d8, 0x0), at 0xfefbc9f4 >>>> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xff19e338 >>>> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x60338, 0x0), at 0xfefbc9f4 >>>> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4a5d >>>> 00, 0x0), at 0xfeff6db4 >>>> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >>>> 0xfe1b2000 >>>> , 0x6e5a0, 0x0), at 0xfefbc9f4 >>>> (dbx) >>>> (dbx) threads >>>>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >>>> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >>>> ___nanosleep >>>> () >>>> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >>>> in __lwp_pa >>>> rk() >>>> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >>>> ___nanosleep >>>> () >>>> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >>>> in __lwp_pa >>>> rk() >>>> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >>>> in __lwp_pa >>>> rk() >>>> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >>>> in __lwp_pa >>>> rk() >>>> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >>>> __lwp_kill( >>>> ) >>>> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >>>> in __lwp_pa >>>> rk() >>>> (dbx) >>>> >>>> >>>> The crashing thread: >>>> >>>> (dbx) thread t at 27 >>>> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >>>> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >>>> 0xfe3c11f4 >>>> (dbx) where >>>> current thread: t at 27 >>>> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >>>> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >>>> 0xfe35fdd8 >>>> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >>>> 0xfe33fff8 >>>> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >>>> 0xfe46255c >>>> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >>>> 0xfe4529c8 >>>> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >>>> 0xfddf0900), at 0x >>>> fe44f2e4 >>>> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >>>> 0xfe4b4d90, 0xff2 >>>> 50434), at 0xfe44ee5c >>>> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >>>> 0x100000), >>>> at 0xfe44fa0c >>>> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, >>>> 0x12345678 >>>> ), >>>> at 0xfe44f590 >>>> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>>> 0xfffffff8, 0x0, >>>> 0xfdc53131), at 0xfe44f44c >>>> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >>>> 0x0), at 0xfe46 >>>> 470c >>>> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, >>>> 0x12345678 >>>> ), >>>> at 0xfe44f680 >>>> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>>> 0xfffffff8, 0x0, >>>> 0xfdc53661), at 0xfe44f44c >>>> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >>>> 0x0, 0xfdc538 >>>> e1), at 0xfe46470c >>>> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >>>> 0xfdc53a40, 0xfdc539 >>>> 2c, 0xfdc53928), at 0xfe42ffe0 >>>> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >>>> 0xfdc53a40), a >>>> t 0xff141d64 >>>> >>>> (too many frames for an assertion failure imho!) >>>> >>>> >>>> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >>>> 0x1000, 0x0, >>>> 0x0), at 0xff13dda4 >>>> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >>>> 0xff000000, 0x0, >>>> 0x0), at 0xff13d9e8 >>>> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >>>> 0xfddf0800, >>>> 0x69da0, 0x0), at 0xff140730 >>>> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >>>> 0xff000000, 0xff00000 >>>> 0, 0x0, 0x1), at 0xff1407d0 >>>> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >>>> 0xfdd221bc), a >>>> t 0xfefb8f04 >>>> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >>>> 0xfefc5170 >>>> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >>>> 0xfddf0800, 0x90 >>>> 410, 0x0), at 0xfefc45a8 >>>> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >>>> 0xfefc4674 >>>> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >>>> 0xfe46bc00 >>>> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >>>> 0xfe46b740, 0x1) >>>> , at 0xfe46b790 >>>> (dbx) >>>> >>>> >>>> - Jay From hosking at cs.purdue.edu Mon Jul 27 15:56:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Jul 2009 09:56:44 -0400 Subject: [M3devel] gcc error on PPC_DARWIN In-Reply-To: References: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> Message-ID: <567D958D-EBCE-4358-8D97-80688C544CAD@cs.purdue.edu> -m32 should work. On 27 Jul 2009, at 00:09, Jay K wrote: > > I kind of throw in that everywhere until/unless shown that it hurts > and isn't needed. > Indeed it doesn't always work, not always on gcc, not always on cm3cg. > > > I have this probe in Darwin.common now, since I was using an > AMD64_DARWIN machine the other day: > > > if not defined("SYSTEM_CC") > not this part > if equal(WORD_SIZE, "32BITS") > SYSTEM_CC = "32" > else > SYSTEM_CC = "64" > end > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > SYSTEM_CC = "gcc -fPIC -m" & SYSTEM_CC > local a = SYSTEM_CC & " -arch " & GccArch > this part, with -arch or not > local b = try_exec("@" & a & " -v 2>/dev/null") > if equal(b, 0) > SYSTEM_CC = a > end > %write("SYSTEM_CC is " & SYSTEM_CC & "\n") > end > if not defined("SYSTEM_LIBTOOL") > readonly SYSTEM_LIBTOOL = "libtool" > end > > > which should be redundant with the -m32/64 stuff, so try just: > > > if not defined("SYSTEM_CC") > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > SYSTEM_CC = "gcc -fPIC" > local a = SYSTEM_CC & " -arch " & GccArch > local b = try_exec("@" & a & " -v 2>/dev/null") > if equal(b, 0) > SYSTEM_CC = a > end > %write("SYSTEM_CC is " & SYSTEM_CC & "\n") > end > if not defined("SYSTEM_LIBTOOL") > readonly SYSTEM_LIBTOOL = "libtool" > end > > I know this kind of probing is inefficient -- we do it every > invocation of cm3. > We could at least limit it to if there is a need to compile C or > link -- like how GetM3BackFlags works now (sort of -- not probe > related, but just related to bootstrapping or not). > The alternative is to let users edit or have cminstall do the probe > -- and have it go stale when the tools change.. > > - Jay > > > > > ---------------------------------------- >> Date: Mon, 27 Jul 2009 00:22:58 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] gcc error on PPC_DARWIN >> >> compiler bootstrap on PPC_DARWIN failed with `invalid option 32': >> http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console >> >> Do we really require 64-bit capable tools now on all systems? >> Or did I make some stupid error again? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 27 16:53:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 16:53:08 +0200 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Quoting Tony Hosking : > Not sure if doing it that way works. Current default stack size set in > ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try > changing it there. There used to be a procedure IncreaseDefaultStackSize. IITR we needed that for several M3 applications on some platforms several years ago. But probably we should also set the default for a target platform so that all our own applications are able to run. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 17:24:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 15:24:16 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Message-ID: I don't think this is a stack overflow but I will try that. We should probably drastically increase the defaults. Like make them match whatever the underlying platform uses, or just make sure that unless the user intercedes, that we don't either. The whole notion of a limited size stack is pretty flawed imho. And much worse if you engage in reducing it from the default. How much stack do I need to leave for fopen to work? What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 16:53:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Quoting Tony Hosking : > >> Not sure if doing it that way works. Current default stack size set in >> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >> changing it there. > > There used to be a procedure IncreaseDefaultStackSize. IITR we needed > that for several M3 applications on some platforms several years ago. > > But probably we should also set the default for a target platform > so that all our own applications are able to run. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 18:26:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:26:11 +0000 Subject: [M3devel] extra files in workspace Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248711232.27188 ? cm3/m3-db/db/test/stderr 16 ? cm3/m3-db/odbc/test/stderr 17 ? cm3/m3-db/postgres95/test/stderr 18 ? cm3/m3-db/stable/test/stderr 19 ? cm3/m3-libs/arithmetic/test/stderr 20 ? cm3/m3-libs/binIO/test/PPC_LINUX 21 ? cm3/m3-libs/binIO/test/stderr 22 ? cm3/m3-libs/bitvector/test/stderr 23 ? cm3/m3-libs/libm3/tests/PPC_LINUX 24 ? cm3/m3-libs/libm3/tests/stderr 25 ? cm3/m3-libs/patternmatching/tests/stderr 26 ? cm3/m3-libs/slisp/tests/stderr 27 ? cm3/m3-libs/unittest-numeric/PPC_LINUX 28 ? cm3/m3-sys/cm3/test/PPC_LINUX 29 ? cm3/m3-sys/cm3/test/stderr 30 ? cm3/m3-sys/cm3ide/PPC_LINUX 31 ? cm3/m3-sys/m3cc/tmp-stdout-13571 32 ? cm3/m3-sys/m3quake/test/PPC_LINUX 33 ? cm3/m3-sys/m3quake/test/stderr 34 ? cm3/m3-sys/m3tests/PPC_LINUX 35 ? cm3/m3-sys/m3tests/m3tests-results.xml 36 ? cm3/m3-sys/m3tests/m3tests-results.xml.new 37 ? cm3/m3-sys/m3tests/m3tests.html 38 ? cm3/m3-tools/cvsup/cvpasswd/PPC_LINUX 39 ? cm3/m3-tools/kate/PPC_LINUX 40 ? cm3/m3-tools/m3tohtml/html we might consider having the scripts delete such things at the start of a run. Including what .cvsignore is suppressing (depending on if the desire is to clean or not). Notice that not all are in the derived directory (or rather none are, except the derived directory itself) - Jay From rcoleburn at scires.com Mon Jul 27 18:29:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 27 Jul 2009 12:29:41 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Message-ID: <4A6D9D4E.1E75.00D7.1@scires.com> In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. See the code snippet below: (* stack *) IF pp.keywordPresent("-stack") THEN (* *) TRY (* *) stackMult := pp.getNextInt(min := 1, max := 100); EXCEPT | ParseParams.Error => (* *) pp.error("A number in the range [1..100] must be specified as\n" & "the stack size multiplier after the -stack option.\n"); END; (* try *) END; (* if *) IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy Coleburn >>> Jay K 7/27/2009 11:24 AM >>> I don't think this is a stack overflow but I will try that. We should probably drastically increase the defaults. Like make them match whatever the underlying platform uses, or just make sure that unless the user intercedes, that we don't either. The whole notion of a limited size stack is pretty flawed imho. And much worse if you engage in reducing it from the default. How much stack do I need to leave for fopen to work? What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 16:53:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Quoting Tony Hosking : > >> Not sure if doing it that way works. Current default stack size set in >> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >> changing it there. > > There used to be a procedure IncreaseDefaultStackSize. IITR we needed > that for several M3 applications on some platforms several years ago. > > But probably we should also set the default for a target platform > so that all our own applications are able to run. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 27 18:33:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:33:43 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <4A6D9D4E.1E75.00D7.1@scires.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> <4A6D9D4E.1E75.00D7.1@scires.com> Message-ID: > a command line parameter to set the stack size! This is proof that the mechanism is very flawed. Imagine if all programs accepted a command line parameter to set their stack size, and chosing the right number was critical to their successful operation. !!! - Jay ________________________________ > Date: Mon, 27 Jul 2009 12:29:41 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > > > > > > > In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. > > > > If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. > > > > See the code snippet below: > > > > (* stack *) > IF pp.keywordPresent("-stack") > THEN (* *) > TRY (* *) > stackMult := pp.getNextInt(min := 1, max := 100); > EXCEPT > | ParseParams.Error => (* *) > pp.error("A number in the range [1..100] must be specified as\n" > & "the stack size multiplier after the -stack option.\n"); > END; (* try *) > END; (* if *) > IF stackMult> 1 > THEN > WITH default = Thread.GetDefaultStackSize(), > desired = default * stackMult, > increase = desired - default > DO > PutText("Increasing default stack size by a factor of " & > Fmt.Int(stackMult) & " (" & Fmt.Int(default) & ">>> " & > Fmt.Int(desired) & ").\n"); > Thread.IncDefaultStackSize(increase); > END; (* with *) > WITH default = Thread.GetDefaultStackSize() > DO > PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); > END; (* with *) > END; (* if *) > > > > Regards, > > Randy Coleburn > >>>> Jay K 7/27/2009 11:24 AM>>> > > I don't think this is a stack overflow but I will try that. > We should probably drastically increase the defaults. > Like make them match whatever the underlying platform uses, or just make > sure that unless the user intercedes, that we don't either. > > > The whole notion of a limited size stack is pretty flawed imho. > And much worse if you engage in reducing it from the default. > How much stack do I need to leave for fopen to work? > What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. > Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). > I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) > > > Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. > What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 27 Jul 2009 16:53:08 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> Quoting Tony Hosking : >> >>> Not sure if doing it that way works. Current default stack size set in >>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >>> changing it there. >> >> There used to be a procedure IncreaseDefaultStackSize. IITR we needed >> that for several M3 applications on some platforms several years ago. >> >> But probably we should also set the default for a target platform >> so that all our own applications are able to run. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Mon Jul 27 18:44:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:44:57 +0000 Subject: [M3devel] bad web pages Message-ID: [ sorry if this too rude. I've been avoiding saying anything because I haven't done anything to fix it and because my complaints are a little vague. But I am sure there is something significant here. When something bugs I often wait and see if it stops bugging me, maybe I overreact initially. But this has continued to bug me. ] I'm sorry, but our web pages are not very good. Too much information, too many details presented too early, hard to see the little a new person needs. I don't have the patience right now to go into detail, but starting here: http://www.opencm3.net/releng/ Much too much stuff. Beginners need to quickly get to a download, and quickly have hello world working, and then a link to the language and library documentation. Telling them about packages early is not useful. Having so many options as to what to download is not useful. I admit even my min vs. std separation is not great. It is embarassing either way -- either you are a huge download or you have pitiful little functionality. Though libm3 is not exactly pitiful I gather. They don't care much about quake. Just give one or two quick tutorial examples: - here is how you build a program from multiple source files - optionally here is how you build a library (obviously this information must be provided, but not super early) My other complaint is that I go here: http://modula3.elegosoft.com/ and there is a link "WWW service for CM3 and PM3" Huh? WWW Service? Aren't I already there? Perhaps I just pick a bad starting point? Is the distinction Modula-3 the language vs. the two distributions CM3 and PM3? Maybe we should ignore PM3 and equate Modula-3 with CM3, and somehow merge this stuff? The package download service? Does anyone use it? The problem, the reason I don't rewrite stuff and am just a lazy complainer, is that in total there's a bunch of stuff in there. The way it is laid out is bad. It used to take me a while to find stuff. I can't be very concrete now..maybe the organization has changed..I thought it was the stuff you have to scroll to the bottom for, but I don't use that anymore. One concrete thing is that http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes doesn't need to be so visible, it's spot could be used for something of more general use. I realize that it was more valuable when 5.1 was new, and then its value degraded gradually. It depends how much there is out there that works with 3.x?4.x?PM3 and doesn't work with CM3? Perhaps a very big part of the answer here is deb packages? - add such and such line to whatever file - apt-get modula3-min or modula3-all, or whatever you want in-between? - apt-whatever -list modula3-*? I guess we'd have to call them cm3 not modula3. - Jay From jay.krell at cornell.edu Mon Jul 27 19:17:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 17:17:51 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <4A6D9D4E.1E75.00D7.1@scires.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> <4A6D9D4E.1E75.00D7.1@scires.com> Message-ID: > I don't know of a way to increase the mainline thread stack while it is running. On NT you cannot. The stack size is set when the thread is created. Once the thread is created, that is it. Typical default thread sizes on 32bit NT are 256K and 1MB. Maybe twice that for 64bit. I think there might be a minimum that small requests get rounded up to. VirtualAlloc basically allocates in 64K chunks so you can't likely get smaller than 64K, or 60K if you consider the guard page. Some experimentation would be informative. I've seen gcc stack overflow only on non-Linux..because the default stack on Linux is huge, like 8MB. I guess that's what you get in historically single threaded environments.. If you write an NT kernel driver, then you generally have like 3 4K pages maximum, a very different environment. Basically I consider this area fairly unpredictable. Did I create the thread or did someone else create it and call me? How much stack is required by the code I'm going to call. In the absence of any solutions, best advise for the programmer is to generally conserve stack. If you must recurse, recurse only to a maximum amount determined by your code, not determined by user input. Otherwise large user input will cause you to fail in a hard to handle way. Fixed sized character buffers of 256, 1024, MAX_PATH, etc. are not a good thing to use. Doubly (or even quadruply) bad with Unicode. Despite being very fast. Another option is to use a small buffer like 64 and then heap alloc if the data is large. Or just heap alloc and have a smooth if slow performance curve against data size. At least with the heap, it is pretty much limited by address space, and running out of heap at least in C is very well defined -- you get NULL from malloc. Many people know to check for that. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] the formsedit crash > Date: Mon, 27 Jul 2009 16:33:43 +0000 > > >> a command line parameter to set the stack size! > > This is proof that the mechanism is very flawed. > Imagine if all programs accepted a command line parameter to set their stack size, and chosing the right number was critical to their successful operation. > > !!! > > - Jay > > > > ________________________________ >> Date: Mon, 27 Jul 2009 12:29:41 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> >> >> >> >> >> >> In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. >> >> >> >> If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. >> >> >> >> See the code snippet below: >> >> >> >> (* stack *) >> IF pp.keywordPresent("-stack") >> THEN (* *) >> TRY (* *) >> stackMult := pp.getNextInt(min := 1, max := 100); >> EXCEPT >> | ParseParams.Error => (* *) >> pp.error("A number in the range [1..100] must be specified as\n" >> & "the stack size multiplier after the -stack option.\n"); >> END; (* try *) >> END; (* if *) >> IF stackMult> 1 >> THEN >> WITH default = Thread.GetDefaultStackSize(), >> desired = default * stackMult, >> increase = desired - default >> DO >> PutText("Increasing default stack size by a factor of " & >> Fmt.Int(stackMult) & " (" & Fmt.Int(default) & ">>> " & >> Fmt.Int(desired) & ").\n"); >> Thread.IncDefaultStackSize(increase); >> END; (* with *) >> WITH default = Thread.GetDefaultStackSize() >> DO >> PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); >> END; (* with *) >> END; (* if *) >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay K 7/27/2009 11:24 AM>>> >> >> I don't think this is a stack overflow but I will try that. >> We should probably drastically increase the defaults. >> Like make them match whatever the underlying platform uses, or just make >> sure that unless the user intercedes, that we don't either. >> >> >> The whole notion of a limited size stack is pretty flawed imho. >> And much worse if you engage in reducing it from the default. >> How much stack do I need to leave for fopen to work? >> What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. >> Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). >> I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) >> >> >> Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. >> What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Mon, 27 Jul 2009 16:53:08 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] the formsedit crash >>> >>> Quoting Tony Hosking : >>> >>>> Not sure if doing it that way works. Current default stack size set in >>>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >>>> changing it there. >>> >>> There used to be a procedure IncreaseDefaultStackSize. IITR we needed >>> that for several M3 applications on some platforms several years ago. >>> >>> But probably we should also set the default for a target platform >>> so that all our own applications are able to run. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From eiserlohpp at yahoo.com Mon Jul 27 20:49:57 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 27 Jul 2009 11:49:57 -0700 (PDT) Subject: [M3devel] compiler status lines, output in a burst Message-ID: <34573.39026.qm@web56805.mail.re3.yahoo.com> Hi Guys, I just downloaded the latest tarball, and started compiling it with a compiler built from 20090724 (three days ago). I noticed that the output looked "jerky", unlike the normal behavior. Looking closer, it appears that the compiler descends into a package, announces that it has started, then waits. A few seconds later it emits all the ( new-source -> foo.[im]3 ) and similar lines in one burst. Did someone remove the flush at the end of a line of text? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Mon Jul 27 22:07:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:07:26 +0200 Subject: [M3devel] compiler status lines, output in a burst In-Reply-To: <34573.39026.qm@web56805.mail.re3.yahoo.com> References: <34573.39026.qm@web56805.mail.re3.yahoo.com> Message-ID: <20090727220726.fu6kbgwr3koooowg@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Guys, > > I just downloaded the latest tarball, and started compiling > it with a compiler built from 20090724 (three days ago). > > I noticed that the output looked "jerky", unlike the > normal behavior. Looking closer, it appears that the > compiler descends into a package, announces that it has > started, then waits. A few seconds later it emits all > the ( new-source -> foo.[im]3 ) and similar lines in > one burst. > > Did someone remove the flush at the end of a line of text? That should be fixed easily. Stay tuned, just waiting for a test in Hudson... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 22:49:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:49:26 +0200 Subject: [M3devel] bad web pages In-Reply-To: References: Message-ID: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> No offense taken. Any volunteers for working on improving the web presentation are welcome. The official domains are opencm3.net and modula3.org. Everything else should be left to Elego. I'd really appreciate if someone with the appropriate knowledge in design would step in. I don't think anybody is interested in doing that, though. I'd say that 99% of what is there has been structured and presented by me in the simplest way just to publish the available information at all. Some people have made concrete change suggestions, and I'm usually trying to follow and integrate them. Let's not try a complete overhaul for this release. Just fix the most blatant errors and no-gos. Everything else will take months. The releng pages have been open for discussion here for several weeks now; they are still not public (i.e. not linked to the other pages) of opencm3.net. Suggestions may also simply be checked in (everything is in the repo), preferrably on a branch, so that everyone can have a look at it. It's also much more effective. I haven't got the time to process half a dozen of new and probably conflicting suggestions. What's not open for discussion in my eyes any more is the structure of the release archives. We'll just use what is described there, or it will take months till we get anywhere. It will also be the last time that I coordinate a CM3 release. Everyone around me is already complaining :-( Olaf Quoting Jay K : > [ > sorry if this too rude. > I've been avoiding saying anything because I haven't done anything > to fix it and because my complaints are a little vague. But I am > sure there is something significant here. When something bugs I > often wait and see if it stops bugging me, maybe I overreact > initially. But this has continued to bug me. > ] > > > I'm sorry, but our web pages are not very good. > Too much information, too many details presented too early, hard to > see the little a new person needs. > > > I don't have the patience right now to go into detail, but starting here: > > > http://www.opencm3.net/releng/ > > > Much too much stuff. > > > Beginners need to quickly get to a download, and quickly have hello > world working, and then a link to the language and library > documentation. > > > Telling them about packages early is not useful. > Having so many options as to what to download is not useful. > I admit even my min vs. std separation is not great. > It is embarassing either way -- either you are a huge download or > you have pitiful little functionality. Though libm3 is not exactly > pitiful I gather. > > > They don't care much about quake. > Just give one or two quick tutorial examples: > - here is how you build a program from multiple source files > - optionally here is how you build a library (obviously this > information must be provided, but not super early) > > > My other complaint is that I go here: > > > http://modula3.elegosoft.com/ > > > and there is a link "WWW service for CM3 and PM3" > > Huh? WWW Service? Aren't I already there? > Perhaps I just pick a bad starting point? > > > Is the distinction Modula-3 the language vs. the two distributions > CM3 and PM3? > Maybe we should ignore PM3 and equate Modula-3 with CM3, and somehow > merge this stuff? > > > The package download service? Does anyone use it? > > > The problem, the reason I don't rewrite stuff and am just a lazy > complainer, is that in total there's a bunch of stuff in there. The > way it is laid out is bad. It used to take me a while to find stuff. > > > I can't be very concrete now..maybe the organization has changed..I > thought it was the stuff you have to scroll to the bottom for, but I > don't use that anymore. > > > One concrete thing is that > http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes doesn't > need to be so > visible, it's spot could be used for something of more general use. > I realize that it was more valuable when 5.1 was new, and then its > value degraded gradually. > It depends how much there is out there that works with 3.x?4.x?PM3 > and doesn't work with CM3? > > > > Perhaps a very big part of the answer here is deb packages? > - add such and such line to whatever file > - apt-get modula3-min or modula3-all, or whatever you want in-between? > - apt-whatever -list modula3-*? > > > I guess we'd have to call them cm3 not modula3. > > > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 22:50:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:50:23 +0200 Subject: [M3devel] compiler status lines, output in a burst In-Reply-To: <34573.39026.qm@web56805.mail.re3.yahoo.com> References: <34573.39026.qm@web56805.mail.re3.yahoo.com> Message-ID: <20090727225023.zf2wctvsisgswckw@mail.elegosoft.com> Quoting Peter Eiserloh : > I noticed that the output looked "jerky", unlike the > normal behavior. Looking closer, it appears that the > compiler descends into a package, announces that it has > started, then waits. A few seconds later it emits all > the ( new-source -> foo.[im]3 ) and similar lines in > one burst. should be fixed now Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 28 01:10:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 23:10:15 +0000 Subject: [M3devel] getting Tinderbox to green? Message-ID: Linux/x86, Linux/sparc, Linux/ppc. Sparc hit access denied uploading to birch. Maybe transient network problem. The others succeeded builds, failed tests. Failed tests is normal, right? And should be green? They stay orange. I also see that the yellow doesn't change to green or orange until the next build is started, I'm pretty sure. I somehow got very luck with my one SOLgnu run. It was green on almost my first try. - Jay From jay.krell at cornell.edu Tue Jul 28 05:09:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 03:09:36 +0000 Subject: [M3devel] getting Tinderbox to green? Message-ID: I think on PPC_LINUX I just need to delete the old pkg and lib stores particularly to remove the old libodbc.so. On I386_LINUX there is a different problem linking the db test. I might have to install something extra there. Could be a Gentoo vs. Debian thing. Not likely any real problem in the Modula-3 tree here, but a problem with my machine configuration. SPARC32_LINUX's last run that uploaded had the m3gdb problem, so still waiting to see. Maybe the next runs will go green, maybe. btw, I'm pretty sure this is all feeds directly into Hudson, like, I'm not wasting time on Tinderbox. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: getting Tinderbox to green? > Date: Mon, 27 Jul 2009 23:10:15 +0000 > > > Linux/x86, Linux/sparc, Linux/ppc. > Sparc hit access denied uploading to birch. > Maybe transient network problem. > > The others succeeded builds, failed tests. > Failed tests is normal, right? > And should be green? > They stay orange. > I also see that the yellow doesn't change to green or orange > until the next build is started, I'm pretty sure. > > I somehow got very luck with my one SOLgnu run. > It was green on almost my first try. > > > - Jay > From rcoleburn at scires.com Tue Jul 28 05:24:26 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 27 Jul 2009 23:24:26 -0400 Subject: [M3devel] new install on Windows Vista Message-ID: <4A6E36C0.1E75.00D7.1@scires.com> Jay: I am attempting a new install on Windows Vista. I have a question about the config files. I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? Thanks for your help! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 06:22:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 04:22:25 +0000 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6E36C0.1E75.00D7.1@scires.com> References: <4A6E36C0.1E75.00D7.1@scires.com> Message-ID: [keeping you on the thread in case of truncation] I would do all the clean each package first, then build and ship each, two passes over the list clean in the first pass build and ship in the second That is hard to explain clearly but I think you understand. Given the packages a b c. clean a clean b clean c build a ship a build b ship b build c ship c is what I do, but it should also work as: clean a build a ship a clean b build b ship b clean c build c ship c which is what I think you described. My python files do deal with the config files. You might try reading some of it? (not intended rudely, as evidenced by further explanation here) Here is the current way: for each file name in cvsroot\m3-sys\cminstall\src\config-no-install and cvsroot\m3-sys\cminstall\src\config delete corresponding file in \cm3\bin That is a "cleanup" step. Not applicable if starting from scratch, harmless. mkdir \cm3\bin\config copy cvsroot\m3-sys\cminstall\src\config-no-install \cm3\bin\config create \cm3\bin\cm3.cfg with the following exact contents: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) There is no meta syntax there. - forward slashes work on Windows - path() is a function that returns the directory of the file calling it - HOST is builtin on newer builds and is a good default for TARGET (We should use this in the distribution archives.) Some of this is taste and the system is flexible. If you wanted, you could put all the files in \cm3\bin, or \whatever. You can make cm3.cfg look in various places. That is what I actually do -- I copy cvsroot\m3-sys\cminstall\src\config-no-install\cm3.cfg to \cm3\bin. It ends up picking up %CM3_ROOT%\m3-sys\cminstall\src\config-no-install\TARGET, so I can edit just one file while in development and not keep having to copy it around. Otherwise I'd get an error in one file in \cm3\bin, fix it, and then remember to copy it into the source tree to check it in. > esp. given an aribitrary old minimal installation as a starting point Yes. I recently removed a lot of the very old compatibility but I have used these exact config files with fairly old builds and run upgrade.cmd or upgrade.py. They were meant to work with a wide range of cm3 versions and on multiple platforms. If you want I can put the compatibility back. There were workarounds for bugs, not yet provided features, etc. The workarounds dynamically adapted to what capabilities the cm3/cm3cg they were using had, and they new for newer platforms to just assume things work well. There are more newer platforms than older platforms so it was kind of annoying to carry it all around, but it does work. I can put it back. You might also want to read README.jay that I checked in. I'll summarize it here: create new empty directory, and bin and bin\config thereof. Put cm3 and cm3cg in bin, copy all the config files to bin\config, create cm3.cfg as shown earlier. Given a recent cm3 (e.g. one that supports LONGINT) that is all you need to build the system starting with import-libs or m3core and on up. (import-libs is almost unnecessary. It is a workaround for that - older cm3 builds contained bogus files - some but very few native toolsets don't have the requisite files, like Visual C++ 2003 Express If you have a decent toolset and start with an old cm3, you can just delete the toplevel lib directory to get started and skip import-libs..but it builds super fast anyway). You don't likely even need cm3cg, it just saves time. And you don't need it on NT386 of course. If you have too old of a cm3, then you start with cm3 and pkg\m3core and pkg\libm3, and start with import-libs and sysutils, skipping m3core and libm3. (I'm assuming both m3core and libm3 use LONGINT, if they don't, then..) Oh, also older and even current cm3 can't build certain versions of m3core and/or libm3 (I think just libm3) between old and present due to the platform list. But current m3core and libm3 don't have that problem. m3-sys\cminstall\src\config is dead, as are all the config files around m3-sys\cm3\config. I deleted m3-sys\cm3\config but Tony added some back. I'm trying to wait until after this release to delete a lot of the dead stuff. Trying also to consider if some of it has historical/reference value. Like all the Unix *.i3 files. Maybe just comment those all out instead of deleting them. I know there is CVS history but it much easier to see what is dead and present than dead and gone, as long as there are good hints that it is dead, like commenting out every line. "a lot has changed in the config files since 5.8.1" I imagine would be - removal of compatibility stuff - possibly the use of symlinks and removal of hardlinks - having make_lib call skip_lib - oh, right, refactoring of all the toplevel files to include(architecture) and include(os). That had been bugging me for a long time so I finally did it. Basically the original authors of the config files either - liked monolithic files - didn't consider the proliferation of OS across multiple/many architectures These days we have fairly few OS, but many OS x architecture. NetBSD on everything, Linux on everything, everything else still on a few Let me know if that doesn't answer everything or if you have further questions. Once I have the Tinderbox runs running better on Posix sysetms, I will face the choice for NT386 of using Cygwin sh to drive it all, or rewriting all the .sh in .cmd or .py or .js. I'm strongly considering rewriting in .py. Rewriting is also a good way to gain understanding, you have to read and understand every line. - Jay ________________________________ > Date: Mon, 27 Jul 2009 23:24:26 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] new install on Windows Vista > > > > > > > > Jay: > > > > I am attempting a new install on Windows Vista. I have a question about the config files. > > > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > > > It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. > > > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > > > Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. > > > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. > > > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? > > > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? > > > > Thanks for your help! > > > > Regards, > > Randy Coleburn From lists at darko.org Tue Jul 28 06:47:08 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 06:47:08 +0200 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6E36C0.1E75.00D7.1@scires.com> References: <4A6E36C0.1E75.00D7.1@scires.com> Message-ID: <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> I happen to be doing the same thing at the moment (on XP). Have we got an installer for this in the works? And Inno Setup one should be pretty easy if not. On 28/07/2009, at 5:24 AM, Randy Coleburn wrote: > Jay: > > I am attempting a new install on Windows Vista. I have a question > about the config files. > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > It is unzipped to C:\cm3. Note that I also have a complete checkout > of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also > installed Visual C++ 2008 Express. > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C: > \cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, > hoping that this will indeed upgrade the compiler in the proper > order, based on PkgInfo.txt. If I invoke my script as follows "do- > cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 - > build", and "cm3 -ship" command sequence to each package identified > in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > Perhaps this is a flawed plan; if so, let me know. I know there are > various scripts and python that may already purport to do what I > want to do, but please humor me. I am trying to learn the actual > low-level steps required to do the install and upgrade, beginning > with the minimal distribution. In my view, once I have the minimal > binary distro plus the new sources, I ought to be able to use the > cm3 commands (perhaps scripted) to rebuild everything properly, as > long as I do it in the correct order. > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin > \cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C: > \Sandbox\m3-sys\cminstall\src" we have a config folder and a config- > no-install folder. In the past, I've been copying the contents of > the config-no-install folder to "C:\cm3\bin". (1) Is this correct? > If not, please explain. > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If > not, how/when/should this folder be updated? > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, > it seems a lot has changed, hence my questions. I also wonder that > if someone used the python or other scripts, do these handle > updating the various config stuff, esp. given an aribitrary old > minimal installation as a starting point? > > Thanks for your help! > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 07:04:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 05:04:49 +0000 Subject: [M3devel] new install on Windows Vista In-Reply-To: <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> References: <4A6E36C0.1E75.00D7.1@scires.com> <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi created by automation in cvsroot/scripts/python/pylib.py, via scripts/python/make-dist.py. - Jay ________________________________ > From: lists at darko.org > To: m3devel at elegosoft.com > Date: Tue, 28 Jul 2009 06:47:08 +0200 > Subject: Re: [M3devel] new install on Windows Vista > > I happen to be doing the same thing at the moment (on XP). Have we got an installer for this in the works? And Inno Setup one should be pretty easy if not. > > > On 28/07/2009, at 5:24 AM, Randy Coleburn wrote: > > Jay: > > I am attempting a new install on Windows Vista. I have a question about the config files. > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? > > Thanks for your help! > > Regards, > Randy Coleburn > From wagner at elegosoft.com Tue Jul 28 07:24:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 07:24:59 +0200 Subject: [M3devel] getting Tinderbox to green? In-Reply-To: References: Message-ID: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> Quoting Jay K : > Linux/x86, Linux/sparc, Linux/ppc. > Sparc hit access denied uploading to birch. > Maybe transient network problem. > > The others succeeded builds, failed tests. > Failed tests is normal, right? > And should be green? > They stay orange. That's expected. All release builds were orange as long as I remember. We always had failed tests. > I also see that the yellow doesn't change to green or orange > until the next build is started, I'm pretty sure. That's strange. It should get green/orange/red as soon as the results are in. > I somehow got very luck with my one SOLgnu run. > It was green on almost my first try. So it doesn't run any tests? Just compiles? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lists at darko.org Tue Jul 28 07:24:25 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 07:24:25 +0200 Subject: [M3devel] bad web pages In-Reply-To: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> References: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> Message-ID: I don't think the visiual presentation is the issue, but the oganisation could be improved. I think visiually it should look like the M3 Language Definition and the like. I'll have a go at re- organising it. On 27/07/2009, at 10:49 PM, Olaf Wagner wrote: > No offense taken. Any volunteers for working on improving the > web presentation are welcome. > > The official domains are opencm3.net and modula3.org. > Everything else should be left to Elego. > > I'd really appreciate if someone with the appropriate knowledge > in design would step in. I don't think anybody is interested in > doing that, though. I'd say that 99% of what is there has been > structured and presented by me in the simplest way just to publish > the available information at all. > > Some people have made concrete change suggestions, and I'm usually > trying to follow and integrate them. > > Let's not try a complete overhaul for this release. Just fix the most > blatant errors and no-gos. Everything else will take months. > > The releng pages have been open for discussion here for several weeks > now; they are still not public (i.e. not linked to the other pages) > of opencm3.net. > > Suggestions may also simply be checked in (everything is in the repo), > preferrably on a branch, so that everyone can have a look at it. > It's also much more effective. I haven't got the time to process > half a dozen of new and probably conflicting suggestions. > > What's not open for discussion in my eyes any more is the structure > of the release archives. We'll just use what is described there, > or it will take months till we get anywhere. It will also be the > last time that I coordinate a CM3 release. Everyone around me is > already complaining :-( > > Olaf > > Quoting Jay K : > >> [ >> sorry if this too rude. >> I've been avoiding saying anything because I haven't done anything >> to fix it and because my complaints are a little vague. But I am >> sure there is something significant here. When something bugs I >> often wait and see if it stops bugging me, maybe I overreact >> initially. But this has continued to bug me. >> ] >> >> >> I'm sorry, but our web pages are not very good. >> Too much information, too many details presented too early, hard >> to see the little a new person needs. >> >> >> I don't have the patience right now to go into detail, but starting >> here: >> >> >> http://www.opencm3.net/releng/ >> >> >> Much too much stuff. >> >> >> Beginners need to quickly get to a download, and quickly have >> hello world working, and then a link to the language and library >> documentation. >> >> >> Telling them about packages early is not useful. >> Having so many options as to what to download is not useful. >> I admit even my min vs. std separation is not great. >> It is embarassing either way -- either you are a huge download or >> you have pitiful little functionality. Though libm3 is not exactly >> pitiful I gather. >> >> >> They don't care much about quake. >> Just give one or two quick tutorial examples: >> - here is how you build a program from multiple source files >> - optionally here is how you build a library (obviously this >> information must be provided, but not super early) >> >> >> My other complaint is that I go here: >> >> >> http://modula3.elegosoft.com/ >> >> >> and there is a link "WWW service for CM3 and PM3" >> >> Huh? WWW Service? Aren't I already there? >> Perhaps I just pick a bad starting point? >> >> >> Is the distinction Modula-3 the language vs. the two distributions >> CM3 and PM3? >> Maybe we should ignore PM3 and equate Modula-3 with CM3, and >> somehow merge this stuff? >> >> >> The package download service? Does anyone use it? >> >> >> The problem, the reason I don't rewrite stuff and am just a lazy >> complainer, is that in total there's a bunch of stuff in there. >> The way it is laid out is bad. It used to take me a while to find >> stuff. >> >> >> I can't be very concrete now..maybe the organization has >> changed..I thought it was the stuff you have to scroll to the >> bottom for, but I don't use that anymore. >> >> >> One concrete thing is that http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes >> doesn't need to be so >> visible, it's spot could be used for something of more general use. >> I realize that it was more valuable when 5.1 was new, and then its >> value degraded gradually. >> It depends how much there is out there that works with 3.x?4.x?PM3 >> and doesn't work with CM3? >> >> >> >> Perhaps a very big part of the answer here is deb packages? >> - add such and such line to whatever file >> - apt-get modula3-min or modula3-all, or whatever you want in- >> between? >> - apt-whatever -list modula3-*? >> >> >> I guess we'd have to call them cm3 not modula3. >> >> >> - Jay >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Jul 28 07:41:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 05:41:44 +0000 Subject: [M3devel] getting Tinderbox to green? In-Reply-To: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> References: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> Message-ID: > That's expected. All release builds were orange as long as I remember. > We always had failed tests. But your builds are green. I think there might be two measures of test failure. Building the tests vs. running the tests? I still have build failures wrt db. I think that is holding it up. Tony's Solaris runs do too. http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-SOLgnu.html#tr_m3-db-odbc >> I somehow got very luck with my one SOLgnu run. >> It was green on almost my first try. > So it doesn't run any tests? Just compiles? Yeah you are right: [start run-tests 2009.07.26 05:08:06] 6600 cd /tmp/build-cm3-20090726-031802-jMaOBg/build 6601 [end run-tests 2009.07.26 05:08:06] I must have forgotten to comment out to run the tests. I think the reason my earlier builds never finished was probably they were hung trying to scp/ssh to birch without the username fixed. I thought it was something related to not running the tests, but now I doubt that. I guess the way to get green asap is remove that edit and don't run the tests at all. I'll try not to go that way though. Hot weather this week also, not sure what I'm going to do.. - Jay From eiserlohpp at yahoo.com Tue Jul 28 08:37:08 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 27 Jul 2009 23:37:08 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 33, Issue 104 Message-ID: <28748.61011.qm@web56806.mail.re3.yahoo.com> Hi Olaf, I just wanted to say thank you! You have been doing a great job. A compiler and development environment such as CM3 is a very large software suite, and to coordinate a software release is never an easy job. Sure the web pages can use some sprucing up, big deal! Like you said, all the web pages are in the CVS repo, any one with write access to the repo could change them. It may seem like there is a lot of complaining, and it is, but what has everyone jazzed up at the moment (okay last few months), is that shortly, all the work we have been doing will be seeing a much larger audience, and we want our favorite project to look its best. What we all should remember is that we all have real lives, away from the computer and modula-3. None of us has enough time to do _everything_ we want. BTW: I just wanted bring your attention to my latest build of Debian packages for AMD64_LINUX on "lenny". I built it today from cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. http://www.eiserloh.org/mirrors/modula3/ If you have a Debian-lenn-AM64 machine, could you try it out. Maybe, even download the source package, and try building it yourself. The source package should work with any architecture supported by Debian. Please comment on any improvements I can make to these debian packages. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > Date: Mon, 27 Jul 2009 22:49:26 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] bad web pages It will also be the > last time that I coordinate a CM3 release. Everyone around > me is already complaining :-( > > Olaf From lists at darko.org Tue Jul 28 09:24:38 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 09:24:38 +0200 Subject: [M3devel] Dependency on msvcr80.dll Message-ID: After intalling the latest VC++ Express which is 2008 or version 9 and building with your min distribution I found it was dependent on msvcr80.dll. Is this hard coded somewhere - should it use the msvcr90.dll? Is there a correct way to resolve it? Cheers, Darko. From jay.krell at cornell.edu Tue Jul 28 09:28:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 07:28:25 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: This is a problem I found and reported here last week. Until otherwise figured out, we have to provide a build per supported toolset/runtime. It is built into the binaries/libraries, it is their dependencies. I don't fully understand what is going on. Just because m3core.dll uses a particular .dll, does not foist that direct dependency on its users. However if you want to get malloced pointer from it and then free it, or an fopen FILE* from it and fread/fclose it, then you do have to agree. malloc is very easy to do without, and besides, most/all of this stuff is wrapped up -- you know, if you call UntracedHeapAllocate (whatever it is called) you can't then call free, you have to call UntracedHeapFree (whatever it is called) - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Subject: Dependency on msvcr80.dll > Date: Tue, 28 Jul 2009 09:24:38 +0200 > CC: m3devel at elegosoft.com > > After intalling the latest VC++ Express which is 2008 or version 9 and > building with your min distribution I found it was dependent on > msvcr80.dll. Is this hard coded somewhere - should it use the > msvcr90.dll? Is there a correct way to resolve it? > > Cheers, > Darko. > From jay.krell at cornell.edu Tue Jul 28 09:28:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 07:28:54 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: (and I opened a Trac ticket too) ---------------------------------------- > From: jay.krell at cornell.edu > To: lists at darko.org > CC: m3devel at elegosoft.com > Subject: RE: Dependency on msvcr80.dll > Date: Tue, 28 Jul 2009 07:28:25 +0000 > > > This is a problem I found and reported here last week. > > > Until otherwise figured out, we have to provide a build per supported toolset/runtime. > It is built into the binaries/libraries, it is their dependencies. > > > I don't fully understand what is going on. > > > Just because m3core.dll uses a particular .dll, does not foist that direct dependency on its users. However if you want to get malloced pointer from it and then free it, or an fopen FILE* from it and fread/fclose it, then you do have to agree. > > > malloc is very easy to do without, and besides, most/all of this stuff is wrapped up -- you know, if you call UntracedHeapAllocate (whatever it is called) you can't then call free, you have to call UntracedHeapFree (whatever it is called) > > > - Jay > > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Subject: Dependency on msvcr80.dll >> Date: Tue, 28 Jul 2009 09:24:38 +0200 >> CC: m3devel at elegosoft.com >> >> After intalling the latest VC++ Express which is 2008 or version 9 and >> building with your min distribution I found it was dependent on >> msvcr80.dll. Is this hard coded somewhere - should it use the >> msvcr90.dll? Is there a correct way to resolve it? >> >> Cheers, >> Darko. >> From jay.krell at cornell.edu Tue Jul 28 11:35:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 09:35:31 +0000 Subject: [M3devel] odbc errors Message-ID: odbc errors Tony, everyone, please read and then do like this: rm -rf /usr/local/cm3/pkg/*odbc* rm -rf /usr/local/cm3/lib/*odbc* cd root/cm3/m3-db rm -rf odbc cvs -z3 upd -dAP odbc cd odbc cm3 cm3 -ship cd ~/work/cm3-inst find . | grep odbc | xargs rm - Jay From hendrik at topoi.pooq.com Tue Jul 28 11:39:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Jul 2009 05:39:32 -0400 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) In-Reply-To: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> References: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> Message-ID: <20090728093932.GA7708@topoi.pooq.com> On Mon, Jul 27, 2009 at 03:31:55PM +0200, Olaf Wagner wrote: > Quoting Jay K : > > >CVS checkout and update of an entire tree seem to be extremely unreliable. > >It takes a while and often times out. > > It should not take longer than about 5 minutes, and considering > the number of files and amount of data to be transferred, that's > quite acceptable. > > If we really run out of resources on birch, we may need to set up > a public r/o copy of the repository for cvs access. Or switch to a distrubited system like monotone, which I've been able to spend far too little time on lately. Sorry. -- hendrik From jay.krell at cornell.edu Tue Jul 28 11:40:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 09:40:33 +0000 Subject: [M3devel] odbc errors In-Reply-To: References: Message-ID: In the cm3-inst case you can just rm -rf */lib */pkg. You don't need them at the start of a Tinderbox run, at least not for last-ok. You do need them for last-rel I believe though (I've never run that). I've also deleted my entire lib and pkg install for good measure, but I know I can easily rebuild them and the "work/cm3-inst" is more important right now, that's where Tinderbox/Hudson work. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Tue, 28 Jul 2009 09:35:31 +0000 > Subject: [M3devel] odbc errors > > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay From jay.krell at cornell.edu Tue Jul 28 12:40:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 10:40:40 +0000 Subject: [M3devel] executable named "test" Message-ID: I noticed I had an executable named "test" in my cm3 install. It is related to caltech-parser, but I don't know exactly where it came from, or if it is still being produced. There is no capital P Program("test") just lowercase program("test") which means they only ship to the pkg directory and not bin. Just a note for folks to check for this and delete it. It probably only occurs if you have run the Tinderbox/Hudson stuff. And even then I'm not sure how/when/where/why. - Jay From hendrik at topoi.pooq.com Tue Jul 28 12:51:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Jul 2009 06:51:37 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <20090728105137.GC7708@topoi.pooq.com> On Sat, Jul 18, 2009 at 11:50:13PM +0000, Jay K wrote: > > cm3ide is quite unusual in being browser based and that really limits > it, esp. targeting browsers from long ago with just a bunch of html, > using Flash or Silverlight can result in a browser-based app as good > as a non-browser-based app. Please, don't require proprietary stuff in the browser. -- hendrik From jay.krell at cornell.edu Tue Jul 28 14:07:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 12:07:50 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: Try these that I just made? They were built with VC 9.0: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip I didn't test them (too much combinatorial explosion -- four things to test!) and the readme from before: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt Olaf, there is a LOT more in the snaps directory than the snapshot-index lists. A lot. Also my archives contain more of the licenses, so many that I put them in a subdirectory. - Jay From wagner at elegosoft.com Tue Jul 28 14:24:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 14:24:50 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: <20090728142450.ksxo5jvx8gkoksco@mail.elegosoft.com> Quoting Jay K : > Try these that I just made? > > They were built with VC 9.0: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip > > I didn't test them (too much combinatorial explosion -- four things to test!) > > and the readme from before: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt > > Olaf, there is a LOT more in the snaps directory than the > snapshot-index lists. > A lot. Also my archives contain more of the licenses, so many that I > put them in a subdirectory. Yes. Feel free to fix ;-) Or just open a ticket for the next release... It's probably just a pattern mismatch (snapshot lists, not copyrights). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 28 14:45:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 12:45:33 +0000 Subject: [M3devel] too many loops through packages? Message-ID: Tinderbox run..compile done, tests running..and I see m3gdb running configure. I think extra work is being done.. I guess it is a bunch of incremental builds and they don't take long? - Jay From wagner at elegosoft.com Tue Jul 28 15:05:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 15:05:38 +0200 Subject: [M3devel] too many loops through packages? In-Reply-To: References: Message-ID: <20090728150538.1h0ac4s2og0cg0os@mail.elegosoft.com> Quoting Jay K : > Tinderbox run..compile done, tests running..and I see m3gdb running > configure. > I think extra work is being done.. > I guess it is a bunch of incremental builds and they don't take long? There are not really incremental builds in Tinderbox. Everything is checked out fresh and built from scratch. And there are several tests performing the same builds with slightly different contexts or targets. I'm trying to make the Hudson builds a little bit more incremental. m3cc is already factored out; m3gdb should be, too. The rest (M3 :-) builds really fast. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Jul 28 15:39:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 09:39:45 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: Message-ID: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, so exactly what should I be deleting? And why? On 28 Jul 2009, at 05:35, Jay K wrote: > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 15:51:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 13:51:42 +0000 Subject: [M3devel] odbc errors In-Reply-To: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: Whereever you have it installed. The Modula-3 libodbc* was perhaps in conflict with other libodbc*. There were at least warnings to this affect in some builds. So it was renamed libm3odbc. However the old one isn't automatically deleted. I think we can always delete it -- assuming that cm3 libraries aren't in the same directory as non-cm3 libraries but Olaf said not to. If you look at your Solaris Tinderbox test results you will see some red I believe caused by this -- not deleting the old cm3 libodbc, whereever it is. I /think/ this failure to /build/ the tests is why the red or orange status on Tinderbox instead of green. But I'm not sure yet since I haven't gotten things to turn green yet. Maybe we can only get green on the builds that don't run the tests?...er..yeah that would explain why only lastok builds are green and lastrelease builds are not..so I guess I can declare success on Linux x86/ppc/sparc.. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Jul 2009 09:39:45 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] odbc errors > > Umm, I am confused. On my niagara box I don't have /usr/local/cm3, so exactly what should I be deleting? And why? > > On 28 Jul 2009, at 05:35, Jay K wrote: > > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay > From hosking at cs.purdue.edu Tue Jul 28 17:36:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 11:36:39 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: OK, deleting those now. On 28 Jul 2009, at 09:51, Jay K wrote: > > Whereever you have it installed. > > > The Modula-3 libodbc* was perhaps in conflict with other libodbc*. > There were at least warnings to this affect in some builds. > So it was renamed libm3odbc. However the old one isn't automatically > deleted. > I think we can always delete it -- assuming that cm3 libraries > aren't in the same directory as non-cm3 libraries but Olaf said not > to. > > > If you look at your Solaris Tinderbox test results you will see some > red I believe caused by this -- not deleting the old cm3 libodbc, > whereever it is. > > > I /think/ this failure to /build/ the tests is why the red or orange > status on Tinderbox instead of green. > But I'm not sure yet since I haven't gotten things to turn green yet. > Maybe we can only get green on the builds that don't run the > tests?...er..yeah that would explain why only lastok builds are > green and lastrelease builds are not..so I guess I can declare > success on Linux x86/ppc/sparc.. > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Jul 2009 09:39:45 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] odbc errors >> >> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, >> so exactly what should I be deleting? And why? >> >> On 28 Jul 2009, at 05:35, Jay K wrote: >> >> >> odbc errors >> >> Tony, everyone, please read and then do like this: >> >> rm -rf /usr/local/cm3/pkg/*odbc* >> rm -rf /usr/local/cm3/lib/*odbc* >> cd root/cm3/m3-db >> rm -rf odbc >> cvs -z3 upd -dAP odbc >> cd odbc >> cm3 >> cm3 -ship >> >> >> cd ~/work/cm3-inst >> find . | grep odbc | xargs rm >> >> >> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 28 17:44:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 11:44:50 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: I don't have any libodbc installed anywhere in my tinderbox builds. Must be something else going on. On 28 Jul 2009, at 11:36, Tony Hosking wrote: > OK, deleting those now. > > > On 28 Jul 2009, at 09:51, Jay K wrote: > >> >> Whereever you have it installed. >> >> >> The Modula-3 libodbc* was perhaps in conflict with other libodbc*. >> There were at least warnings to this affect in some builds. >> So it was renamed libm3odbc. However the old one isn't >> automatically deleted. >> I think we can always delete it -- assuming that cm3 libraries >> aren't in the same directory as non-cm3 libraries but Olaf said not >> to. >> >> >> If you look at your Solaris Tinderbox test results you will see >> some red I believe caused by this -- not deleting the old cm3 >> libodbc, whereever it is. >> >> >> I /think/ this failure to /build/ the tests is why the red or >> orange status on Tinderbox instead of green. >> But I'm not sure yet since I haven't gotten things to turn green yet. >> Maybe we can only get green on the builds that don't run the >> tests?...er..yeah that would explain why only lastok builds are >> green and lastrelease builds are not..so I guess I can declare >> success on Linux x86/ppc/sparc.. >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Jul 2009 09:39:45 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] odbc errors >>> >>> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, >>> so exactly what should I be deleting? And why? >>> >>> On 28 Jul 2009, at 05:35, Jay K wrote: >>> >>> >>> odbc errors >>> >>> Tony, everyone, please read and then do like this: >>> >>> rm -rf /usr/local/cm3/pkg/*odbc* >>> rm -rf /usr/local/cm3/lib/*odbc* >>> cd root/cm3/m3-db >>> rm -rf odbc >>> cvs -z3 upd -dAP odbc >>> cd odbc >>> cm3 >>> cm3 -ship >>> >>> >>> cd ~/work/cm3-inst >>> find . | grep odbc | xargs rm >>> >>> >>> - Jay >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 28 22:45:27 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Jul 2009 16:45:27 -0400 Subject: [M3devel] new install on Windows Vista Message-ID: <4A6F2B27020000D70005D660@scires.com> Jay: You stated: >>> Jay K 07/28/09 12:24 AM >>> create \cm3\bin\cm3.cfg with the following exact contents: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) I am looking at the cm3.cfg you supplied with the d5.8.2.zip file. It has the following: INSTALL_ROOT = (path() & "/..") include(path() & "/config/NT386") Should it be HOST or NT386 ? Also, are the extra parenthesis in the first line needed? Thanks for your help. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 22:52:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Jul 2009 13:52:40 -0700 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6F2B27020000D70005D660@scires.com> References: <4A6F2B27020000D70005D660@scires.com> Message-ID: Host or nt386 ok. Host is like target but is the running cm3, vs. what it is building, often the same thing and using host here makes them the same. (native build vs. cross build) Parens probably not needed right. If it works it is right. It won't appear to work but do the wrong thing. - Jay (phone) On Jul 28, 2009, at 1:45 PM, "Randy Coleburn" wrote: > Jay: > > You stated: > >>> Jay K 07/28/09 12:24 AM >>> > create \cm3\bin\cm3.cfg with the following exact contents: > INSTALL_ROOT = path() & "/.." > include(path() & "/config/" & HOST) > > I am looking at the cm3.cfg you supplied with the d5.8.2.zip file. > It has the following: > INSTALL_ROOT = (path() & "/..") > include(path() & "/config/NT386") > Should it be HOST or NT386 ? > Also, are the extra parenthesis in the first line needed? > > Thanks for your help. > --Randy From lists at darko.org Wed Jul 29 04:33:03 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 29 Jul 2009 04:33:03 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Yep, they work. Can you only use the version of VC that the compiler was built with? On 28/07/2009, at 2:07 PM, Jay K wrote: > > Try these that I just made? > > They were built with VC 9.0: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip > > I didn't test them (too much combinatorial explosion -- four things > to test!) > > and the readme from before: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt > > Olaf, there is a LOT more in the snaps directory than the snapshot- > index lists. > A lot. Also my archives contain more of the licenses, so many that I > put them in a subdirectory. > > > - Jay From jay.krell at cornell.edu Wed Jul 29 05:16:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 03:16:26 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> References: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Message-ID: The compiler isn't relevant. The libraries are. You might as well consider them as one indivisable unit, but they aren't quite. I don't yet fully understand the situation. Until/unless I/we do, we'll build a distribution per VC version. I should have renamed the below cm3-min-NT386-d5.8.2-vc90.zip or such but I was lazy and took advantage of there being no other 5.8.2 currently. Stay tuned (but don't hold your breath) for cm3-min-NT386-d5.8.2-vc80.zip and speak up as to which, IF ANY, of these is desired: cm3-min-NT386-d5.8.2-vc71.zip cm3-min-NT386-d5.8.2-vc70.zip cm3-min-NT386-d5.8.2-vc60.zip cm3-min-NT386-d5.8.2-vc50.zip cm3-min-NT386-d5.8.2-vc42.zip cm3-min-NT386-d5.8.2-vc41.zip cm3-min-NT386-d5.8.2-vc40.zip cm3-min-NT386-d5.8.2-vc20.zip (I haven't yet acquired the 32bit 1.0 version, but all the others have been tested surprisingly recently.) For that matter, among: Borland 5.5 (free "beer") Metrowerks 6, 7, 8 Digital Mars (free "beer") Open Watcom (free and open source) speak up as to which, IF ANY, are desired, and what to call the target. My experiment to call everything NT386 I've decided was a failure. I'll fix that in the next release. I386_NT_DIGITALMARS, I386_NT_WATCOM, I386_NT_CODEWARRIOR, I386_NT_BORLAND ? I386_NT_DMARS, I386_NT_WAT, I386_CW I386_NT_MWCW, I386_NT_BOR??? Borland seems to still be under development but current versions are expensive. I guess I should learn the jmpbuf size of all of those and see if everyone is close and if so use the largest of them. Then it's simply a matter of ensuring we use C wrappers enough (probably already do), and getting the compiler/linker switches reasonable on the config files. - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Date: Wed, 29 Jul 2009 04:33:03 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Dependency on msvcr80.dll > > Yep, they work. Can you only use the version of VC that the compiler > was built with? > > > On 28/07/2009, at 2:07 PM, Jay K wrote: > >> >> Try these that I just made? >> >> They were built with VC 9.0: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip >> >> I didn't test them (too much combinatorial explosion -- four things >> to test!) >> >> and the readme from before: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt >> >> Olaf, there is a LOT more in the snaps directory than the snapshot- >> index lists. >> A lot. Also my archives contain more of the licenses, so many that I >> put them in a subdirectory. >> >> >> - Jay > From lists at darko.org Wed Jul 29 08:24:29 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 29 Jul 2009 08:24:29 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Message-ID: I think the latestest will suffice, since it sounds pretty easy to derive any other version from that one, and the latest VC version is freely available. The other compilers I wouldn't worry about since users probably don't exist, and if they do then they can use those products pretty easily with the VC command line tools. I use Metrowerks for instance (on the Mac) and have hacked a plugin that does most of what I want. Anyway, I'd hate to keep you from the much more interesting ARM_DARWIN :-) On 29/07/2009, at 5:16 AM, Jay K wrote: > > The compiler isn't relevant. > The libraries are. > You might as well consider them as one indivisable unit, but they > aren't quite. > I don't yet fully understand the situation. > Until/unless I/we do, we'll build a distribution per VC version. I > should have renamed the below > cm3-min-NT386-d5.8.2-vc90.zip or such but I was lazy and took > advantage of there being no other 5.8.2 currently. > > > Stay tuned (but don't hold your breath) for > cm3-min-NT386-d5.8.2-vc80.zip > > > and speak up as to which, IF ANY, of these is desired: > > cm3-min-NT386-d5.8.2-vc71.zip > cm3-min-NT386-d5.8.2-vc70.zip > cm3-min-NT386-d5.8.2-vc60.zip > cm3-min-NT386-d5.8.2-vc50.zip > cm3-min-NT386-d5.8.2-vc42.zip > cm3-min-NT386-d5.8.2-vc41.zip > cm3-min-NT386-d5.8.2-vc40.zip > cm3-min-NT386-d5.8.2-vc20.zip > (I haven't yet acquired the 32bit 1.0 version, but all the others > have been tested surprisingly recently.) > > > For that matter, among: > Borland 5.5 (free "beer") > Metrowerks 6, 7, 8 > Digital Mars (free "beer") > Open Watcom (free and open source) > > speak up as to which, IF ANY, are desired, and what to call the > target. > My experiment to call everything NT386 I've decided was a failure. > I'll fix that in the next release. > I386_NT_DIGITALMARS, I386_NT_WATCOM, I386_NT_CODEWARRIOR, > I386_NT_BORLAND ? > I386_NT_DMARS, I386_NT_WAT, I386_CW I386_NT_MWCW, I386_NT_BOR??? > Borland seems to still be under development but current versions are > expensive. > > I guess I should learn the jmpbuf size of all of those and see if > everyone is close and if so use the largest of them. Then it's > simply a matter of ensuring we use C wrappers enough (probably > already do), and getting the compiler/linker switches reasonable on > the config files. > > > - Jay > > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Wed, 29 Jul 2009 04:33:03 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Dependency on msvcr80.dll >> >> Yep, they work. Can you only use the version of VC that the compiler >> was built with? >> >> >> On 28/07/2009, at 2:07 PM, Jay K wrote: >> >>> >>> Try these that I just made? >>> >>> They were built with VC 9.0: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip >>> >>> I didn't test them (too much combinatorial explosion -- four things >>> to test!) >>> >>> and the readme from before: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt >>> >>> Olaf, there is a LOT more in the snaps directory than the snapshot- >>> index lists. >>> A lot. Also my archives contain more of the licenses, so many that I >>> put them in a subdirectory. >>> >>> >>> - Jay >> From rcoleburn at scires.com Wed Jul 29 13:14:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 07:14:57 -0400 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) Message-ID: <4A6FF67C.1E75.00D7.1@scires.com> Update on NT386 build (Windows XP, Microsoft Visual C++ Express 2008), R.Coleburn ===================================================================== Here are the errors and warnings I am seeing currently in building the minimal installation: --- processing package "m3-libs\libm3" --- --- building in NT386 --- "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) 1 warning encountered Here is a list of all packages that I am building: m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-sys\windowsResources m3-libs\patternmatching m3-libs\sysutils m3-libs\unittest m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3staloneback m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3scanner m3-sys\m3tools m3-sys\m3cgcat m3-sys\m3cggen m3-sys\m3gdb m3-tools\m3bundle m3-sys\mklib m3-sys\fix_nl m3-sys\libdump m3-libs\arithmetic m3-libs\unittest-numeric m3-libs\bitvector m3-libs\digraph m3-libs\parseparams m3-libs\realgeometry m3-libs\set m3-libs\slisp m3-libs\sortedtableextras m3-libs\table-list m3-libs\tempfiles m3-libs\tcl m3-comm\tcp m3-sys\cm3ide m3-comm\udp m3-libs\libsio m3-libs\libbuf m3-libs\debug m3-libs\listfuncs m3-libs\embutils m3-libs\m3tk-misc m3-www\http m3-libs\binIO m3-libs\commandrw m3-comm\tapi m3-comm\serial m3-tools\m3tk m3-tools\mtex m3-tools\m3totex m3-tools\m3tohtml m3-tools\m3scan m3-tools\m3markup m3-tools\m3browser m3-tools\cmpdir m3-tools\cmpfp m3-tools\dirfp m3-tools\uniq m3-comm\netobj m3-comm\netobjd m3-comm\stubgen m3-comm\events m3-comm\rdwr m3-comm\sharedobj m3-comm\sharedobjgen m3-db\odbc m3-db\postgres95 m3-db\db m3-db\smalldb m3-db\stablegen m3-db\stable m3-ui\X11R4 m3-ui\ui m3-ui\PEX m3-ui\vbtkit m3-ui\cmvbt m3-ui\jvideo m3-ui\videovbt m3-www\web m3-www\proxy m3-ui\formsvbtpixmaps m3-ui\formsvbt m3-ui\formsview m3-ui\formsedit m3-ui\codeview m3-tools\cvsup\suplib m3-tools\cvsup\client m3-tools\cvsup\server m3-tools\cvsup\cvpasswd m3-ui\mg m3-ui\mgkit m3-ui\opengl m3-ui\anim3D m3-ui\zeus m3-ui\m3zume m3-obliq\synloc m3-obliq\synex m3-obliq\metasyn m3-obliq\obliqrt m3-obliq\obliqparse m3-obliq\obliqprint m3-obliq\obliq m3-obliq\obliqlibemb m3-obliq\obliqlibm3 m3-obliq\obliqlibui m3-obliq\obliqlibanim m3-obliq\obliqsrvstd m3-obliq\obliqsrvui m3-obliq\obliqbinmin m3-obliq\obliqbinstd m3-obliq\obliqbinui m3-obliq\obliqbinanim m3-obliq\obliqlib3D m3-obliq\visualobliq m3-obliq\vocgi m3-obliq\voquery m3-obliq\vorun m3-ui\webvbt m3-tools\recordheap m3-tools\rehearsecode m3-tools\replayheap m3-tools\showheap m3-tools\shownew m3-tools\showthread m3-ui\juno-2\juno-app\pkl-fonts m3-ui\juno-2\juno-machine m3-ui\juno-2\juno-compiler m3-ui\juno-2\juno-app m3-demo\cube m3-demo\calculator m3-demo\fisheye m3-demo\mentor caltech-parser\cit_common caltech-parser\m3tmplhack caltech-parser\cit_util caltech-parser\term m3-libs\deepcopy caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\hack caltech-parser\m3browserhack caltech-parser\parserlib\ktoklib caltech-parser\parserlib\klexlib caltech-parser\parserlib\kyacclib caltech-parser\parserlib\ktok caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib caltech-parser\parserlib\parserlib\test m3-tools\pp m3-tools\kate m3-libs\sgml m3-www\deckscape m3-www\webscape m3-www\webcat m3-ui\bicycle m3-games\badbricks m3-games\columns m3-games\fours m3-games\maze m3-games\solitaire m3-games\tetris ---END-of-List--- Here are the errors and warnings I am seeing currently in building all the packages listed above: --- processing package "m3-sys\m3cc" --- --- building in NT386 --- ignoring ..\src\m3overrides _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MA KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap -disable-intl -di sable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages =m3cg -enable-targets=all -disable-dependency-tracking -disable-fixincludes -dis able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/cm3/Sandbox /cm3/m3-sys/m3cc/src/../NT386/_m3.log 'chmod' is not recognized as an internal or external command, operable program or batch file. 'sh' is not recognized as an internal or external command, operable program or batch file. "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake runtime error: exit 1: sh -ec ./_m3000.sh --procedure-- -line- -file--- exec -- m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args Fatal Error: package build failed --- processing package "m3-libs\libm3" --- --- building in NT386 --- "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) 1 warning encountered --- processing package "m3-sys\cm3" --- --- building in NT386 --- ignoring ..\src\m3overrides missing CM3_VERSION_NUMBER will read version file missing CM3_VERSION_TEXT will read version file missing CM3_LAST_CHANGED will read version file --- processing package "m3-sys\m3gdb" --- nothing attempts to build for this package --- processing package "m3-sys\mklib" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) (UNALIGNED) 1 warning encountered --- processing package "m3-db\postgres95" --- nothing attempts to build for this package --- processing package "m3-ui\X11R4" --- nothing attempts to build for this package --- processing package "m3-ui\PEX" --- nothing attempts to build for this package --- processing package "m3-tools\cvsup\suplib" --- --- processing package "m3-tools\cvsup\client" --- --- processing package "m3-tools\cvsup\server" --- --- processing package "m3-tools\cvsup\cvpasswd" --- nothing attempts to build for these packages --- processing package "m3-ui\anim3D" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Win_OpenGL_Base.m3 "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception is never raised: GraphicsBase.Failure "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: potentially unhandled exception: GraphicsBase.Failure 2 warnings encountered --- processing package "m3-obliq\obliqrt" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling ObValueCB.i3 "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) 1 warning encountered new source -> compiling ObValueCBProxy.i3 "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) 1 warning encountered new source -> compiling ObValueSO.m3 "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) 1 warning encountered new exporters -> recompiling ObValueCBProxy.i3 "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) 1 warning encountered --- processing package "caltech-parser\cit_common" --- --- building in NT386 --- ignoring ..\src\m3overrides unsupported m3_option value: "-X2 at -pg@" unsupported m3_option value: "-g" --- processing package "m3-libs\deepcopy" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling DeepCopy.m3 "..\src\DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory "..\src\DeepCopy.m3", line 61: warning: potentially unhandled exception: "..\src\DeepCopy.m3", line 97: warning: exception is never raised: 3 warnings encountered --- processing package "caltech-parser\parserlib\klexlib" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RegExpTok.m3 "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered --- processing package "caltech-parser\parserlib\parserlib\test" --- --- building in NT386 --- ignoring ..\src\m3overrides C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed --- processing package "m3-tools\pp" --- nothing attempts to build for this package --- processing package "m3-tools\kate" --- --- building in NT386 --- KDESHARE not found; please define it! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jul 29 13:30:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 07:30:25 -0400 Subject: [M3devel] prelim results on Vista Message-ID: <4A6FFA1C.1E75.00D7.1@scires.com> Jay: I tried building on Vista using the approach I outlined earlier, taking into account the config stuff you relayed to me. Thanks. I started with your d5.8.2 minimal binary install, fixed up the config stuff, and built the "min" packages, twice over. I succeeded in building the minimal installation (no fatal errors reported). Then, when trying to build everything, I ran into problems. See the list below. The first package to run into problems (aside from m3cc, which seems to be expected to fail on Windows) is m3-libs\sysutils. The errors stem from a missing Utypes interface. See below: new source -> compiling System.i3 "..\src\System.i3", line 40: unable to find interface (Utypes) "..\src\System.i3", line 37: symbol not exported (Utypes.pid_t) Any ideas on how to resolve? --Randy Coleburn ERROR LOG SUMMARY: ----------------- WARNING: Errors in package m3-sys\m3cc for -build WARNING: Errors in package m3-libs\sysutils for -build WARNING: Errors in package m3-libs\sysutils for -ship WARNING: Errors in package m3-sys\m3middle for -build WARNING: Errors in package m3-sys\m3objfile for -build WARNING: Errors in package m3-sys\m3linker for -build WARNING: Errors in package m3-sys\m3back for -build WARNING: Errors in package m3-sys\m3staloneback for -build WARNING: Errors in package m3-sys\m3front for -build WARNING: Errors in package m3-sys\m3quake for -build WARNING: Errors in package m3-sys\cm3 for -build WARNING: Errors in package m3-sys\m3tools for -build WARNING: Errors in package m3-sys\m3cgcat for -build WARNING: Errors in package m3-sys\m3cggen for -build WARNING: Errors in package m3-sys\mklib for -build WARNING: Errors in package m3-sys\libdump for -build WARNING: Errors in package m3-sys\cm3ide for -build WARNING: Errors in package m3-www\http for -build WARNING: Errors in package m3-tools\m3tohtml for -build WARNING: Errors in package m3-tools\m3browser for -build WARNING: Errors in package m3-www\proxy for -build WARNING: Errors in package m3-obliq\obliqrt for -build WARNING: Errors in package m3-obliq\obliqparse for -build WARNING: Errors in package m3-obliq\obliqprint for -build WARNING: Errors in package m3-obliq\obliq for -build WARNING: Errors in package m3-obliq\obliqlibemb for -build WARNING: Errors in package m3-obliq\obliqlibm3 for -build WARNING: Errors in package m3-obliq\obliqlibui for -build WARNING: Errors in package m3-obliq\obliqlibanim for -build WARNING: Errors in package m3-obliq\obliqsrvstd for -build WARNING: Errors in package m3-obliq\obliqsrvui for -build WARNING: Errors in package m3-obliq\obliqbinmin for -build WARNING: Errors in package m3-obliq\obliqbinstd for -build WARNING: Errors in package m3-obliq\obliqbinui for -build WARNING: Errors in package m3-obliq\obliqbinanim for -build WARNING: Errors in package m3-obliq\obliqlib3D for -build WARNING: Errors in package m3-obliq\visualobliq for -build WARNING: Errors in package m3-obliq\vocgi for -build WARNING: Errors in package m3-obliq\vorun for -build WARNING: Errors in package m3-ui\webvbt for -build WARNING: Errors in package m3-demo\mentor for -build WARNING: Errors in package caltech-parser\parserlib\parserlib\test for -build WARNING: Errors in package m3-libs\sgml for -build WARNING: Errors in package m3-www\deckscape for -build WARNING: Errors in package m3-www\webscape for -build WARNING: Errors in package m3-www\webcat for -build ---END-of-List--- ===END do-cm3=== C:\cm3\Sandbox\scripts\win>cd ..\..\m3-libs\sysutils C:\cm3\Sandbox\m3-libs\sysutils>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling System.i3 "..\src\System.i3", line 40: unable to find interface (Utypes) "..\src\System.i3", line 37: symbol not exported (Utypes.pid_t) 2 errors encountered new source -> compiling System.m3 "..\src\System.m3", line 27: imported interface contains errors (System) 1 error encountered new source -> compiling Confirmation.m3 "..\src\Confirmation.m3", line 5: imported interface contains errors (System) 1 error encountered new source -> compiling ConnectRdWr.m3 "..\src\ConnectRdWr.m3", line 6: imported interface contains errors (System) 1 error encountered new source -> compiling SystemWin32.m3 "..\src\WIN32\SystemWin32.m3", line 27: imported interface contains errors (System) 1 error encountered compilation failed => not building library "sysutils.lib" Fatal Error: package build failed CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 29 13:28:54 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 29 Jul 2009 04:28:54 -0700 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) In-Reply-To: <4A6FF67C.1E75.00D7.1@scires.com> References: <4A6FF67C.1E75.00D7.1@scires.com> Message-ID: Not bad! - Jay (phone) On Jul 29, 2009, at 4:14 AM, "Randy Coleburn" wrote: > Update on NT386 build (Windows XP, Microsoft Visual C++ Express > 2008), R.Coleburn > ===================================================================== > > Here are the errors and warnings I am seeing currently in building > the minimal installation: > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used > (CheckInt32) > 1 warning encountered > > > > Here is a list of all packages that I am building: > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-sys\windowsResources > m3-libs\patternmatching > m3-libs\sysutils > m3-libs\unittest > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3staloneback > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\m3scanner > m3-sys\m3tools > m3-sys\m3cgcat > m3-sys\m3cggen > m3-sys\m3gdb > m3-tools\m3bundle > m3-sys\mklib > m3-sys\fix_nl > m3-sys\libdump > m3-libs\arithmetic > m3-libs\unittest-numeric > m3-libs\bitvector > m3-libs\digraph > m3-libs\parseparams > m3-libs\realgeometry > m3-libs\set > m3-libs\slisp > m3-libs\sortedtableextras > m3-libs\table-list > m3-libs\tempfiles > m3-libs\tcl > m3-comm\tcp > m3-sys\cm3ide > m3-comm\udp > m3-libs\libsio > m3-libs\libbuf > m3-libs\debug > m3-libs\listfuncs > m3-libs\embutils > m3-libs\m3tk-misc > m3-www\http > m3-libs\binIO > m3-libs\commandrw > m3-comm\tapi > m3-comm\serial > m3-tools\m3tk > m3-tools\mtex > m3-tools\m3totex > m3-tools\m3tohtml > m3-tools\m3scan > m3-tools\m3markup > m3-tools\m3browser > m3-tools\cmpdir > m3-tools\cmpfp > m3-tools\dirfp > m3-tools\uniq > m3-comm\netobj > m3-comm\netobjd > m3-comm\stubgen > m3-comm\events > m3-comm\rdwr > m3-comm\sharedobj > m3-comm\sharedobjgen > m3-db\odbc > m3-db\postgres95 > m3-db\db > m3-db\smalldb > m3-db\stablegen > m3-db\stable > m3-ui\X11R4 > m3-ui\ui > m3-ui\PEX > m3-ui\vbtkit > m3-ui\cmvbt > m3-ui\jvideo > m3-ui\videovbt > m3-www\web > m3-www\proxy > m3-ui\formsvbtpixmaps > m3-ui\formsvbt > m3-ui\formsview > m3-ui\formsedit > m3-ui\codeview > m3-tools\cvsup\suplib > m3-tools\cvsup\client > m3-tools\cvsup\server > m3-tools\cvsup\cvpasswd > m3-ui\mg > m3-ui\mgkit > m3-ui\opengl > m3-ui\anim3D > m3-ui\zeus > m3-ui\m3zume > m3-obliq\synloc > m3-obliq\synex > m3-obliq\metasyn > m3-obliq\obliqrt > m3-obliq\obliqparse > m3-obliq\obliqprint > m3-obliq\obliq > m3-obliq\obliqlibemb > m3-obliq\obliqlibm3 > m3-obliq\obliqlibui > m3-obliq\obliqlibanim > m3-obliq\obliqsrvstd > m3-obliq\obliqsrvui > m3-obliq\obliqbinmin > m3-obliq\obliqbinstd > m3-obliq\obliqbinui > m3-obliq\obliqbinanim > m3-obliq\obliqlib3D > m3-obliq\visualobliq > m3-obliq\vocgi > m3-obliq\voquery > m3-obliq\vorun > m3-ui\webvbt > m3-tools\recordheap > m3-tools\rehearsecode > m3-tools\replayheap > m3-tools\showheap > m3-tools\shownew > m3-tools\showthread > m3-ui\juno-2\juno-app\pkl-fonts > m3-ui\juno-2\juno-machine > m3-ui\juno-2\juno-compiler > m3-ui\juno-2\juno-app > m3-demo\cube > m3-demo\calculator > m3-demo\fisheye > m3-demo\mentor > caltech-parser\cit_common > caltech-parser\m3tmplhack > caltech-parser\cit_util > caltech-parser\term > m3-libs\deepcopy > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\hack > caltech-parser\m3browserhack > caltech-parser\parserlib\ktoklib > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\kyacclib > caltech-parser\parserlib\ktok > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib > caltech-parser\parserlib\parserlib\test > m3-tools\pp > m3-tools\kate > m3-libs\sgml > m3-www\deckscape > m3-www\webscape > m3-www\webcat > m3-ui\bicycle > m3-games\badbricks > m3-games\columns > m3-games\fours > m3-games\maze > m3-games\solitaire > m3-games\tetris > ---END-of-List--- > > > > Here are the errors and warnings I am seeing currently in building > all the packages listed above: > > --- processing package "m3-sys\m3cc" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch > lex.yy.c' MA > KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap - > disable-intl -di > sable-libgomp -disable-libmudflap -disable-libssp -disable-nls - > enable-languages > =m3cg -enable-targets=all -disable-dependency-tracking -disable- > fixincludes -dis > able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/ > cm3/Sandbox > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > 'chmod' is not recognized as an internal or external command, > operable program or batch file. > 'sh' is not recognized as an internal or external command, > operable program or batch file. > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake > runtime error: > exit 1: sh -ec ./_m3000.sh > --procedure-- -line- -file--- > exec -- > m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc > \NT386\m3make.args > Fatal Error: package build failed > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used > (CheckInt32) > 1 warning encountered > > > --- processing package "m3-sys\cm3" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > --- processing package "m3-sys\m3gdb" --- > nothing attempts to build for this package > > > --- processing package "m3-sys\mklib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Main.m3 > "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) > (UNALIGNED) > 1 warning encountered > > > --- processing package "m3-db\postgres95" --- > nothing attempts to build for this package > > > --- processing package "m3-ui\X11R4" --- > nothing attempts to build for this package > > > --- processing package "m3-ui\PEX" --- > nothing attempts to build for this package > > > --- processing package "m3-tools\cvsup\suplib" --- > --- processing package "m3-tools\cvsup\client" --- > --- processing package "m3-tools\cvsup\server" --- > --- processing package "m3-tools\cvsup\cvpasswd" --- > nothing attempts to build for these packages > > > --- processing package "m3-ui\anim3D" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Win_OpenGL_Base.m3 > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception > is never raised: GraphicsBase.Failure > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: > potentially unhandled exception: GraphicsBase.Failure > 2 warnings encountered > > > --- processing package "m3-obliq\obliqrt" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling ObValueCB.i3 > "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueSO.m3 > "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) > 1 warning encountered > new exporters -> recompiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > > > --- processing package "caltech-parser\cit_common" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > unsupported m3_option value: "-X2 at -pg@" > unsupported m3_option value: "-g" > > > --- processing package "m3-libs\deepcopy" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling DeepCopy.m3 > "..\src\DeepCopy.m3", line 56: warning: potentially unhandled > exception: RTAllocator.OutOfMemory > "..\src\DeepCopy.m3", line 61: warning: potentially unhandled > exception: > "..\src\DeepCopy.m3", line 97: warning: exception is never raised: > > 3 warnings encountered > > > --- processing package "caltech-parser\parserlib\klexlib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling RegExpTok.m3 > "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled > exception: RTAllocator.OutOfMemory > 1 warning encountered > > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src > \Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime > error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok > \NT386\ktok ..\src\Calc.t -o CalcTok.i3 > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\NT386\m3make.args > Fatal Error: package build failed > > > --- processing package "m3-tools\pp" --- > nothing attempts to build for this package > > > --- processing package "m3-tools\kate" --- > --- building in NT386 --- > KDESHARE not found; please define it! > > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 29 14:06:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 14:06:46 +0200 Subject: [M3devel] Release engineering / OpenBSD status Message-ID: <20090729140646.2o9p3lcz4gc404s0@mail.elegosoft.com> Finally all relevant builds and tests have succeeded on OpenBSD in Hudson, too. See http://hudson.modula3.com:8080/view/I386_OPENBSD/ There are several package build/test failures though: http://hudson.modula3.com:8080/view/I386_OPENBSD/job/cm3-test-all-pkgs-I386_OPENBSD/lastBuild/testReport/ Some of these might be expected (no DB installation and other missing pre-requisites), but if anybody doesn't know how to spend his/her time, s/he might have a look at these (and fix them if possible). There are also 16 failures in m3-sys/m3tests: http://hudson.modula3.com:8080/view/I386_OPENBSD/job/cm3-test-m3tests-I386_OPENBSD/ In general everything looks much better than some days ago; the regression tests finally seem to stabilize. The failures currently visible in Hudson are all master/slave communication problems, and there's not one build red in the tinderbox :-) I think we should be able to build packages soon. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 29 14:27:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 14:27:27 +0200 Subject: [M3devel] M3devel Digest, Vol 33, Issue 104 In-Reply-To: <28748.61011.qm@web56806.mail.re3.yahoo.com> References: <28748.61011.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090729142727.296t56l5u9wc0sg8@mail.elegosoft.com> Hi Peter, thanks for your encouragement. Regression builds look much better today, I think we may be able to have RC2 packages at the weekend. Though I'll have to attend to some other business then, too, like mawing the lawn in the garden ;-) I hope I'll find the time to work on your suggestions for the web presentation then, too. As for the Debian packages you've built, we should definitely link them on the release pages. But I doubt that I'll have time to test them. I trust that others will do that before the release though. Will your web server be able to manage several downloads, or should we copy them over to birch (which is usually heavily loaded most of the time), too? Olaf Quoting Peter Eiserloh : > Hi Olaf, > > I just wanted to say thank you! You have been doing a > great job. A compiler and development environment such > as CM3 is a very large software suite, and to coordinate > a software release is never an easy job. > > Sure the web pages can use some sprucing up, big deal! > Like you said, all the web pages are in the CVS repo, any > one with write access to the repo could change them. > > It may seem like there is a lot of complaining, and it is, > but what has everyone jazzed up at the moment (okay last > few months), is that shortly, all the work we have been > doing will be seeing a much larger audience, and we want > our favorite project to look its best. > > What we all should remember is that we all have real lives, > away from the computer and modula-3. None of us has enough > time to do _everything_ we want. > > BTW: I just wanted bring your attention to my latest build > of Debian packages for AMD64_LINUX on "lenny". I built it > today from cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. > > http://www.eiserloh.org/mirrors/modula3/ > > If you have a Debian-lenn-AM64 machine, could you try it > out. Maybe, even download the source package, and try > building it yourself. The source package should work with > any architecture supported by Debian. > > Please comment on any improvements I can make to these > debian packages. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > >> Date: Mon, 27 Jul 2009 22:49:26 +0200 >> From: Olaf Wagner >> Subject: Re: [M3devel] bad web pages > It will also be the >> last time that I coordinate a CM3 release. Everyone around >> me is already complaining :-( >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 19:42:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 17:42:22 +0000 Subject: [M3devel] unused warning isn't transitive Message-ID: TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; (* We need v to be inside a record. Otherwise, the language would allow a compiler to actually allocate more than the BITS 32 for a value of type Swap.Int32. *) VAR Int32RecVar : Int32Rec; VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); Compiler complains that CheckInt32 isn't used. It should also perhaps mention Int32RecVar therefore. - Jay From jay.krell at cornell.edu Wed Jul 29 20:18:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 18:18:30 +0000 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) In-Reply-To: References: <4A6FF67C.1E75.00D7.1@scires.com> Message-ID: (formatting possibly all messed up sorry) --- processing package "m3-sys\cm3" --- --- building in NT386 --- ignoring ..\src\m3overrides missing CM3_VERSION_NUMBER will read version file missing CM3_VERSION_TEXT will read version file missing CM3_LAST_CHANGED will read version file This is arguably a failing of your .cmd. The other .sh/.py/.cmd define these. Perhaps we should always do it in the m3makefile, nowhere else, and don't warn? Or maybe it is supposed to be fixed for the entire build? Or maybe Olaf just likes to write non portable .sh, in scripts, instead of in m3makefile? (where he can still write non portable .sh, but I have to port it, either way, difference is whether or not it gets written twice or four times, twice is Posix and Win32 in m3makefile, four times is Olaf's .sh, my .py, possibly maybe my .cmd, and your .cmd) Try the .py. Tell me what errors you get. Please. There are contradictory principles at work here: reduce dependencies don't duplicate work We are duplicating work. And I might continue to -- I might rewrite more of Olaf's .sh in .py. But my argument is that it is then more portable and the duplication can then be stopped. (Granted there are sticking points, like MIPS64_OPENBSD possibly and I386_MSDOS possibly, but sh's portability is also overstated, e.g. Solaris..) You can try my .cmd too, but I'd really like to know why the Python doesn't work for you. The .sh, .py, my .cmd, and indirectly the m3makefile read the scripts/version file. Which btw should maybe be at the root? Maybe. It depends on if you feel "scripts" are "official" or merely "convenience". And if "version" is "official" -- don't mix "official" with "convenience"? Not a big deal. Many of the warnings are in generated code, which is partly why I've long ignored them. Plus that I'm lazy. We can try putting in in the generated code. I just hope the compiler isn't a stickler then and complains that sometimes there is nothing to not warn about (like when you say but use it; geez, maybe my intent was, I may or may not use, just shut up either way?) I'll see what I can do, but none or almost none of this is Windows specific. Nobody seems to care much. That unaligned thing is different. - I thought it didn't warn on NT, just others. It possibly needs to be honored on all. - The Modula-3 language is difficient here in general. We need to be able to state alignment if we do want to "interoperate directly" with external data. Normally I say "write C wrappers" but this is a file format not a super cheap little in-memory struct. We almost need to be able to state alignments higher than we can today. I've seen stuff like: setjmp.h: gccism(alignment hgher than Modula-3 allows one to state) comment(less alignment is ok, but more is better) and Modula-3 uses less. Maybe it is yucky and not ANSI C but all the compilers have various extensions to finely control layout. Either we wrap everything up, or unpack from bytes, or copy those C features. Roughly speaking. I'll probably look into "unpack from bytes". Interfacing with the external world sometimes is ugly business and that's just tough; you can't change it. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Wed, 29 Jul 2009 04:28:54 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] update on NT386 build (Windows XP, VC 2008) > > Not bad! > > - Jay (phone) > > On Jul 29, 2009, at 4:14 AM, "Randy Coleburn"> wrote: > > > Update on NT386 build (Windows XP, Microsoft Visual C++ Express 2008), R.Coleburn > ===================================================================== > > > Here are the errors and warnings I am seeing currently in building the minimal installation: > > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) > 1 warning encountered > > > > > > > > Here is a list of all packages that I am building: > > > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-sys\windowsResources > m3-libs\patternmatching > m3-libs\sysutils > m3-libs\unittest > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3staloneback > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\m3scanner > m3-sys\m3tools > m3-sys\m3cgcat > m3-sys\m3cggen > m3-sys\m3gdb > m3-tools\m3bundle > m3-sys\mklib > m3-sys\fix_nl > m3-sys\libdump > m3-libs\arithmetic > m3-libs\unittest-numeric > m3-libs\bitvector > m3-libs\digraph > m3-libs\parseparams > m3-libs\realgeometry > m3-libs\set > m3-libs\slisp > m3-libs\sortedtableextras > m3-libs\table-list > m3-libs\tempfiles > m3-libs\tcl > m3-comm\tcp > m3-sys\cm3ide > m3-comm\udp > m3-libs\libsio > m3-libs\libbuf > m3-libs\debug > m3-libs\listfuncs > m3-libs\embutils > m3-libs\m3tk-misc > m3-www\http > m3-libs\binIO > m3-libs\commandrw > m3-comm\tapi > m3-comm\serial > m3-tools\m3tk > m3-tools\mtex > m3-tools\m3totex > m3-tools\m3tohtml > m3-tools\m3scan > m3-tools\m3markup > m3-tools\m3browser > m3-tools\cmpdir > m3-tools\cmpfp > m3-tools\dirfp > m3-tools\uniq > m3-comm\netobj > m3-comm\netobjd > m3-comm\stubgen > m3-comm\events > m3-comm\rdwr > m3-comm\sharedobj > m3-comm\sharedobjgen > m3-db\odbc > m3-db\postgres95 > m3-db\db > m3-db\smalldb > m3-db\stablegen > m3-db\stable > m3-ui\X11R4 > m3-ui\ui > m3-ui\PEX > m3-ui\vbtkit > m3-ui\cmvbt > m3-ui\jvideo > m3-ui\videovbt > m3-www\web > m3-www\proxy > m3-ui\formsvbtpixmaps > m3-ui\formsvbt > m3-ui\formsview > m3-ui\formsedit > m3-ui\codeview > m3-tools\cvsup\suplib > m3-tools\cvsup\client > m3-tools\cvsup\server > m3-tools\cvsup\cvpasswd > m3-ui\mg > m3-ui\mgkit > m3-ui\opengl > m3-ui\anim3D > m3-ui\zeus > m3-ui\m3zume > m3-obliq\synloc > m3-obliq\synex > m3-obliq\metasyn > m3-obliq\obliqrt > m3-obliq\obliqparse > m3-obliq\obliqprint > m3-obliq\obliq > m3-obliq\obliqlibemb > m3-obliq\obliqlibm3 > m3-obliq\obliqlibui > m3-obliq\obliqlibanim > m3-obliq\obliqsrvstd > m3-obliq\obliqsrvui > m3-obliq\obliqbinmin > m3-obliq\obliqbinstd > m3-obliq\obliqbinui > m3-obliq\obliqbinanim > m3-obliq\obliqlib3D > m3-obliq\visualobliq > m3-obliq\vocgi > m3-obliq\voquery > m3-obliq\vorun > m3-ui\webvbt > m3-tools\recordheap > m3-tools\rehearsecode > m3-tools\replayheap > m3-tools\showheap > m3-tools\shownew > m3-tools\showthread > m3-ui\juno-2\juno-app\pkl-fonts > m3-ui\juno-2\juno-machine > m3-ui\juno-2\juno-compiler > m3-ui\juno-2\juno-app > m3-demo\cube > m3-demo\calculator > m3-demo\fisheye > m3-demo\mentor > caltech-parser\cit_common > caltech-parser\m3tmplhack > caltech-parser\cit_util > caltech-parser\term > m3-libs\deepcopy > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\hack > caltech-parser\m3browserhack > caltech-parser\parserlib\ktoklib > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\kyacclib > caltech-parser\parserlib\ktok > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib > caltech-parser\parserlib\parserlib\test > m3-tools\pp > m3-tools\kate > m3-libs\sgml > m3-www\deckscape > m3-www\webscape > m3-www\webcat > m3-ui\bicycle > m3-games\badbricks > m3-games\columns > m3-games\fours > m3-games\maze > m3-games\solitaire > m3-games\tetris > ---END-of-List--- > > > > > > > > Here are the errors and warnings I am seeing currently in building all the packages listed above: > > > > --- processing package "m3-sys\m3cc" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MA > KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap -disable-intl -di > sable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages > =m3cg -enable-targets=all -disable-dependency-tracking -disable-fixincludes -dis > able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/cm3/Sandbox > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > 'chmod' is not recognized as an internal or external command, > operable program or batch file. > 'sh' is not recognized as an internal or external command, > operable program or batch file. > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake runtime error: > exit 1: sh -ec ./_m3000.sh > --procedure-- -line- -file--- > exec -- > m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args > Fatal Error: package build failed > > > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) > 1 warning encountered > > > > > --- processing package "m3-sys\cm3" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > > > --- processing package "m3-sys\m3gdb" --- > nothing attempts to build for this package > > > > > --- processing package "m3-sys\mklib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Main.m3 > "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) (UNALIGNED) > 1 warning encountered > > > > > --- processing package "m3-db\postgres95" --- > nothing attempts to build for this package > > > > > --- processing package "m3-ui\X11R4" --- > nothing attempts to build for this package > > > > > --- processing package "m3-ui\PEX" --- > nothing attempts to build for this package > > > > > --- processing package "m3-tools\cvsup\suplib" --- > --- processing package "m3-tools\cvsup\client" --- > --- processing package "m3-tools\cvsup\server" --- > --- processing package "m3-tools\cvsup\cvpasswd" --- > nothing attempts to build for these packages > > > > > --- processing package "m3-ui\anim3D" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Win_OpenGL_Base.m3 > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception is never raised: GraphicsBase.Failure > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: potentially unhandled exception: GraphicsBase.Failure > 2 warnings encountered > > > > > --- processing package "m3-obliq\obliqrt" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling ObValueCB.i3 > "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueSO.m3 > "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) > 1 warning encountered > new exporters -> recompiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > > > > > --- processing package "caltech-parser\cit_common" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > unsupported m3_option value: "-X2 at -pg@" > unsupported m3_option value: "-g" > > > > > --- processing package "m3-libs\deepcopy" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling DeepCopy.m3 > "..\src\DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory > "..\src\DeepCopy.m3", line 61: warning: potentially unhandled exception: > "..\src\DeepCopy.m3", line 97: warning: exception is never raised: > 3 warnings encountered > > > > > --- processing package "caltech-parser\parserlib\klexlib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling RegExpTok.m3 > "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory > 1 warning encountered > > > > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > Fatal Error: package build failed > > > > > --- processing package "m3-tools\pp" --- > nothing attempts to build for this package > > > > > --- processing package "m3-tools\kate" --- > --- building in NT386 --- > KDESHARE not found; please define it! > > > > > Regards, > > Randy Coleburn > From wagner at elegosoft.com Wed Jul 29 20:34:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 20:34:25 +0200 Subject: [M3devel] m3cc build broken Message-ID: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> It looks as if the m3cc builds have broken after the last commit to the release branch: http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ error: ignoring ../src/m3overrides "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 292: quake runtime error: undefined variable: build_dir --procedure-- -line- -file--- m3cc_Run 292 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile include_dir 485 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile 4 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args Fatal Error: package build failed What's going on there? Why is build_dir suddenly undefined? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 21:12:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 19:12:54 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> Message-ID: sorry, fixed now, agreed it is odd, I don't understand, undid my simple seeming change - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 20:34:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3cc build broken > > It looks as if the m3cc builds have broken after the last > commit to the release branch: > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > error: > ignoring ../src/m3overrides > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 292: quake runtime error: undefined variable: > build_dir > > --procedure-- -line- -file--- > m3cc_Run 292 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > include_dir 485 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > 4 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > What's going on there? Why is build_dir suddenly undefined? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 29 21:23:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 21:23:39 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> Message-ID: <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Quoting Jay K : > sorry, fixed now, agreed it is odd, I don't understand, undid my > simple seeming change Never mind. The make-dist.sh script seems to be broken, too. Have a look at the end of http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. I guess I'll postpone package build again... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 21:58:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 19:58:04 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Message-ID: Whatever that was, can you run it again? Maybe with set -x? Which one? Searching for 'sed -e'... C:\dev2\cm3.2\scripts\boot-cm3-core.sh(30): sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-${CROSS_TARGET}/cm3cg\";" \ C:\dev2\cm3.2\scripts\find-packages.sh(23): grep /src/m3makefile | grep -v examples | grep -v _darcs | sed -e 's;/src/m3makefile$;;' | C:\dev2\cm3.2\scripts\find-packages.sh(24): sort | uniq | sed -e "s;^./;;" C:\dev2\cm3.2\scripts\find-src-dirs.sh(23): sed -e 's;/m3makefile$;;' -e 's;^;dir ;' C:\dev2\cm3.2\scripts\list-pkg-dirs.sh(39):for d in `listpkgs "$@" | sed -e "s;\$;/src;"`; do C:\dev2\cm3.2\scripts\list-pkg-dirs.sh(41):done | sed -e "s;^;${PREFIX};" C:\dev2\cm3.2\scripts\make-bin-dist-min.sh(107): sed -e ' C:\dev2\cm3.2\scripts\make-dist.sh(220): pw="`echo $p | sed -e 's;/;\\;g'`" C:\dev2\cm3.2\scripts\make-doc-dist.sh(48): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-script-dist.sh(39): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-all.sh(49): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-gnu.sh(51): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-std.sh(55): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-sys.sh(57): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-update.sh(58): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\pkginfo.sh(94): a=`echo $a | sed -e "s;^${ROOT}/;;"` C:\dev2\cm3.2\scripts\pkginfo.sh(96): a=`echo $a | sed -e '/\//!s;^;/;'` C:\dev2\cm3.2\scripts\pkginfo.sh(99): done | sed -e "s;^;${ROOT}/;" C:\dev2\cm3.2\scripts\pkginfo.sh(101): cat "$PKGSDB" | sed -e "s;^;${ROOT}/;" C:\dev2\cm3.2\scripts\pkgmap.sh(221): echo "$1" | sed -e 's/&/&/g' -e 's//\>/g' C:\dev2\cm3.2\scripts\pkgmap.sh(234): pname=`echo $1 | sed -e 's;/;-;g'` C:\dev2\cm3.2\scripts\sysinfo.sh(241): CM3ROOT="`cygpath -w ${ROOT} | sed -e 's;\\\;\\\\\\\\;g'`" C:\dev2\cm3.2\scripts\regression\defs.sh(10):TESTHOSTNAME=${TESTHOSTNAME:-`hostname | sed -e 's/\..*//'`} C:\dev2\cm3.2\scripts\regression\defs.sh(311): R=`cygpath -w $1 | sed -e 's/\\\\/\\\\\\\\\\\\\\\\/g'` C:\dev2\cm3.2\scripts\regression\defs.sh(364): pat=`echo "${WS}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(370): pat=`echo "${RLOG}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(376): pat=`echo "${M3TOUT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(381): pat=`echo "${M3TERR}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(386): pat=`echo "${M3TERR}.extract" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(392): pat=`echo "${CM3_SNAPSHOT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(398): pat=`echo "${HTML_REPORT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\tinderbox-build.sh(28):UNAME_R=`uname -r | sed -e 's/[^A-Za-z0-9_]/./g'` C:\dev2\cm3.2\scripts\regression\update_changelog.sh(16):WSPAT=`echo ${WS} | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\update_m3tests.sh(20): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_pkg_status.sh(20): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_snapshot_status.sh(27): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_snapshot_status.sh(30): sed -e "s/${FNPAT2s}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | 37 occurrence(s) have been found. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 21:23:39 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cc build broken > > Quoting Jay K : > >> sorry, fixed now, agreed it is odd, I don't understand, undid my >> simple seeming change > > Never mind. The make-dist.sh script seems to be broken, too. > Have a look at the end of > http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. > > I guess I'll postpone package build again... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 29 22:31:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 22:31:25 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Message-ID: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Quoting Jay K : > Whatever that was, can you run it again? Maybe with set -x? I hope that works. Watch http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-lastok-build-AMD64_LINUX/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 00:16:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 22:16:56 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: making install.cmd ++ chmod 755 install.sh ++ echo 'REM ---BEGIN---' ++ echo '@echo off' ++ printf 'for %%%%p in (' ++ for p in '${PKGS}' +++ echo m3-demo/cube +++ sed -e 's;/;\;g' sed: -e expression #1, char 7: unterminated `s' command I'll rewrite this later. But wait, I'll give you a preview. install.cmd or setup.cmd shall be a constant file, checked in. Next to it shall be deposited file with a name and format largely of your own chosing. Maybe even with Unix newlines. Certainly forward slashes are fine. Obviously the file would just be a list of relative paths to cd to. I have a slight preference for setup.cmd over install.cmd because setup.exe is common on Windows and install.cmd is slightly ambiguous with Unix /usr/bin/install. Or call it m3ship.cmd or m3setup.cmd or whatever. The name doesn't matter. It will be a constant file, checked in. Pick a name, stake a claim -- checkin an empty file somewhere (scripts?), have your .sh copy it to where you want (the root of the relevant tree), put your text file next to it, I'll fill in the code later. The text file likely is in the same directory as the .cmd. The name can be constant and/or it can be based on the cmd name. foo.cmd => foo.cmd.txt or foo.txt. If you really don't want two files, then do this: Grab the stub .cmd. Append your data to it. But prepend each line with something special. And have "something special" start with "@rem". What the .cmd can do is run findstr on itself. e.g: set self=%~f0 like argv[] for /f %%a in ('findstr /b /c:"@rem special marker" %self%"') do call :F1 %%a goto :eof :F1 more code goto :eof : append your data here. Odds are high that this will actually be JScript code but that's ok, you can embed it in a .cmd file and the technique of finding a file next to self or data appended to self still apply (like people do with Perl with pl2bat). Oh sorry one more suggestion -- this setup could also be written in Modula-3. Not a bad idea. If it is, I recommend NOT static linking, but instead putting m3core.dll/libm3.dll next to it, as a special case, and not having them also be in the derived directory. That optimizes the size overall. It could also likely be quake. Also not a bad idea. I can never glean from the huge usage statement if there is a way to ask cm3 to just run some quake code, or if only prepend/append contents to whatever its normally will search for.. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 22:31:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cc build broken > > Quoting Jay K : > >> Whatever that was, can you run it again? Maybe with set -x? > > I hope that works. Watch > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-lastok-build-AMD64_LINUX/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 30 01:09:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 23:09:37 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: ---------------------------------------- > From: jay > To: wagner > CC: m3devel > Subject: RE: [M3devel] m3cc build broken > Date: Wed, 29 Jul 2009 22:16:56 +0000 > > > making install.cmd > ++ chmod 755 install.sh > ++ echo 'REM ---BEGIN---' > ++ echo '@echo off' > ++ printf 'for %%%%p in (' > ++ for p in '${PKGS}' > +++ echo m3-demo/cube > +++ sed -e 's;/;\;g' > sed: -e expression #1, char 7: unterminated `s' command > > Or just remove the sed and be done. cd accepts forward slashes on Windows. C:\>cd 1/2/3/4 C:\1\2\3\4> - Jay From wagner at elegosoft.com Thu Jul 30 01:25:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 01:25:48 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: <20090730012548.0fsufbg62o0g8ow8@mail.elegosoft.com> Quoting Jay K : > > ---------------------------------------- >> From: jay >> To: wagner >> CC: m3devel >> Subject: RE: [M3devel] m3cc build broken >> Date: Wed, 29 Jul 2009 22:16:56 +0000 >> >> >> making install.cmd >> ++ chmod 755 install.sh >> ++ echo 'REM ---BEGIN---' >> ++ echo '@echo off' >> ++ printf 'for %%%%p in (' >> ++ for p in '${PKGS}' >> +++ echo m3-demo/cube >> +++ sed -e 's;/;\;g' >> sed: -e expression #1, char 7: unterminated `s' command > > Or just remove the sed and be done. > cd accepts forward slashes on Windows. Let's start with that. We can call it setup.cmd if you like. You can change the structure later. > C:\>cd 1/2/3/4 > > C:\1\2\3\4> I haven't found anything explaining the abstract method error. I'll just try to build everything manually first and see how far we get. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jul 30 01:36:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 19:36:45 -0400 Subject: [M3devel] package groups question Message-ID: <4A70A456.1E75.00D7.1@scires.com> In reviewing PkgInfo.txt, I find that the "min" group has the following 3 members: m3-win\import-libs m3-libs\m3core m3-libs\libm3 Are these really all that is needed to build the "minimal" binary distribution? I also ran across group "front" whose members are: m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\mklib What is the purpose of this group? Just in case anyone is interested, my "do-cm3.cmd" script has the capability to enumerate the package groupings. Here is what I find: C:\cm3\Sandbox\scripts\win>do-cm3 showtags all ====== --------------------------------- do-cm3, v1.07, 7/29/2009, Randy Coleburn ====== --------------------------------- CM3 ARGS = showtags PkgInfo = C:\cm3\Sandbox\scripts\pkginfo.txt Pkg Tree = C:\cm3\Sandbox\ Group = all Enumerating group tags in "C:\cm3\Sandbox\scripts\pkginfo.txt" ... ... one moment please ... Group Tags: ---------- base core front min std gui comm caltech-parser m3gnudevtool devlib tool m3gdb math m3devtool obliq webdev database anim cvsup juno demo game ---END-of-LIST--- Enumerating group "all" ... one moment please ... Packages in Group="base": ------------------------------------------------------------------------------ import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3bundle mklib bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp tapi serial ---END-of-List--- Packages in Group="core": ------------------------------------------------------------------------------ import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3front m3quake cm3 m3scanner m3tools m3bundle mklib bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp ---END-of-List--- Packages in Group="front": ------------------------------------------------------------------------------ import-libs m3cc m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 mklib ---END-of-List--- Packages in Group="min": ------------------------------------------------------------------------------ import-libs m3core libm3 ---END-of-List--- Packages in Group="std": ------------------------------------------------------------------------------ import-libs m3core libm3 windowsResources patternmatching sysutils unittest m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle mklib fix_nl libdump arithmetic unittest-numeric bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl tcp cm3ide udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO commandrw tapi serial m3tk mtex m3totex m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db smalldb stablegen stable X11R4 ui PEX vbtkit cmvbt jvideo videovbt m3-www/web m3-www/proxy formsvbtpixmaps formsvbt formsview formsedit codeview cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd mg mgkit opengl anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap shownew showthread juno-2/juno-app/pkl-fonts juno-2/juno-machine juno-2/juno-compiler juno-2/juno-app cube calculator fisheye mentor ---END-of-List--- Packages in Group="gui": ------------------------------------------------------------------------------ import-libs tcp X11R4 ui vbtkit cmvbt jvideo videovbt formsvbtpixmaps formsvbt formsview formsedit opengl webvbt kate m3-ui/bicycle ---END-of-List--- Packages in Group="comm": ------------------------------------------------------------------------------ import-libs tcp udp m3tk-misc tapi serial m3tk netobj netobjd stubgen ---END-of-List--- Packages in Group="caltech-parser": ------------------------------------------------------------------------------ import-libs cit_common m3tmplhack cit_util term paneman paneman/kemacs drawcontext drawcontext/dcpane drawcontext/kgv hack m3browserhack parserlib/ktoklib parserlib/klexlib parserlib/kyacclib parserlib/ktok parserlib/klex parserlib/kyacc parserlib/kext parserlib/parserlib parserlib/parserlib/test ---END-of-List--- Packages in Group="m3gnudevtool": ------------------------------------------------------------------------------ m3cc m3gdb ---END-of-List--- Packages in Group="devlib": ------------------------------------------------------------------------------ windowsResources udp libsio libbuf debug listfuncs m3tk-misc binIO commandrw tapi serial m3tk m3scan m3markup events rdwr deepcopy sgml ---END-of-List--- Packages in Group="tool": ------------------------------------------------------------------------------ m3staloneback m3cgcat m3cggen fix_nl libdump cmpdir cmpfp dirfp uniq ---END-of-List--- Packages in Group="m3gdb": ------------------------------------------------------------------------------ m3gdb ---END-of-List--- Packages in Group="math": ------------------------------------------------------------------------------ arithmetic unittest-numeric ---END-of-List--- Packages in Group="m3devtool": ------------------------------------------------------------------------------ cm3ide m3totex m3tohtml m3browser netobj netobjd stubgen sharedobj sharedobjgen stablegen stable formsview formsedit recordheap rehearsecode replayheap showheap shownew showthread pp ---END-of-List--- Packages in Group="obliq": ------------------------------------------------------------------------------ embutils synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim obliqlib3D visualobliq vocgi voquery vorun ---END-of-List--- Packages in Group="webdev": ------------------------------------------------------------------------------ http m3-www/web m3-www/proxy webvbt deckscape webscape webcat ---END-of-List--- Packages in Group="database": ------------------------------------------------------------------------------ odbc postgres95 db smalldb ---END-of-List--- Packages in Group="anim": ------------------------------------------------------------------------------ codeview mg mgkit anim3D zeus m3zume mentor ---END-of-List--- Packages in Group="cvsup": ------------------------------------------------------------------------------ cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd ---END-of-List--- Packages in Group="juno": ------------------------------------------------------------------------------ juno-2/juno-app/pkl-fonts juno-2/juno-machine juno-2/juno-compiler juno-2/juno-app ---END-of-List--- Packages in Group="demo": ------------------------------------------------------------------------------ cube calculator fisheye ---END-of-List--- Packages in Group="game": ------------------------------------------------------------------------------ m3-games/badbricks m3-games/columns m3-games/fours m3-games/maze m3-games/solitaire m3-games/tetris ---END-of-List--- ===END do-cm3=== C:\cm3\Sandbox\scripts\win> Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 30 02:35:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 00:35:16 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A70A456.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> Message-ID: I'm only going to answer partially for now.. > Are these really all that is needed > to build the "minimal" binary distribution? It depends on what you mean. The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows). That's it. You don't need any packages at all. You don't need m3core/libm3. I setup tinderbox a few times recently. In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far). What that lets you do is build the whole system, from the bottom of the dependency tree and on up. HISTORICALLY there have been some wrinkles here. And it made pretty good sense, I guess, to draw another line. Whether or not that will happen again, unclear. The specific wrinkles were: - Old compiler could not compile a new libm3, if new targets had been added That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler - Old compiler cannot compile m3core or libm3 that uses LONGINT. Now, I have a suspicion that these issues are not extremely rare but just somewhat rare. All compilation systems written in themselves have a circularity. The compiler depends on the compiler. Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make. Let's imagine, crazy, that all the identifiers were changed to lowercase. If "just" change the compiler, well then, you can't build the compiler. You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form. I feel like I might be missing something though. In any case..what are the scenarios? - People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith. Give these people "std" or a bunch of binary packages. These people, in the extreme impatience form, would not even like Olaf's workspace packages. - People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3. Today you give these people cm3, cm3cg, and config files. But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does. The difference in DEC SRC is that quake was written in C, so the division was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose). - Various (infinite) in between situations such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases. Think of the C programmer who uses mainly just printf and malloc. Or the C++ programmer who also uses STL. If you give a programmer m3core/libm3, they are in a similar position. - Jay ________________________________ > Date: Wed, 29 Jul 2009 19:36:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] package groups question > > > > > > > > In reviewing PkgInfo.txt, I find that the "min" group has the following 3 members: > > > m3-win\import-libs > m3-libs\m3core > m3-libs\libm3 > > > > Are these really all that is needed to build the "minimal" binary distribution? > > > > I also ran across group "front" whose members are: > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-libs\sysutils > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\mklib > > > > What is the purpose of this group? > > > > Just in case anyone is interested, my "do-cm3.cmd" script has the capability to enumerate the package groupings. Here is what I find: > > > > > C:\cm3\Sandbox\scripts\win>do-cm3 showtags all > > ====== --------------------------------- > do-cm3, v1.07, 7/29/2009, Randy Coleburn > ====== --------------------------------- > > CM3 ARGS = showtags > PkgInfo = C:\cm3\Sandbox\scripts\pkginfo.txt > Pkg Tree = C:\cm3\Sandbox\ > Group = all > > Enumerating group tags in "C:\cm3\Sandbox\scripts\pkginfo.txt" ... > ... one moment please ... > > Group Tags: > ---------- > base > core > front > min > std > gui > comm > caltech-parser > m3gnudevtool > devlib > tool > m3gdb > math > m3devtool > obliq > webdev > database > anim > cvsup > juno > demo > game > ---END-of-LIST--- > > Enumerating group "all" ... one moment please ... > > Packages in Group="base": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > m3middle > m3quake > m3scanner > m3tools > m3bundle > mklib > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcp > tapi > serial > ---END-of-List--- > > > Packages in Group="core": > ------------------------------------------------------------------------------ > import-libs > m3cc > m3core > libm3 > patternmatching > sysutils > unittest > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > m3scanner > m3tools > m3bundle > mklib > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcp > ---END-of-List--- > > > Packages in Group="front": > ------------------------------------------------------------------------------ > import-libs > m3cc > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > mklib > ---END-of-List--- > > > Packages in Group="min": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > ---END-of-List--- > > > Packages in Group="std": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > windowsResources > patternmatching > sysutils > unittest > m3middle > m3quake > m3scanner > m3tools > m3cgcat > m3cggen > m3gdb > m3bundle > mklib > fix_nl > libdump > arithmetic > unittest-numeric > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcl > tcp > cm3ide > udp > libsio > libbuf > debug > listfuncs > embutils > m3tk-misc > http > binIO > commandrw > tapi > serial > m3tk > mtex > m3totex > m3tohtml > m3scan > m3markup > m3browser > cmpdir > cmpfp > dirfp > uniq > netobj > netobjd > stubgen > events > rdwr > sharedobj > sharedobjgen > odbc > postgres95 > db > smalldb > stablegen > stable > X11R4 > ui > PEX > vbtkit > cmvbt > jvideo > videovbt > m3-www/web > m3-www/proxy > formsvbtpixmaps > formsvbt > formsview > formsedit > codeview > cvsup/suplib > cvsup/client > cvsup/server > cvsup/cvpasswd > mg > mgkit > opengl > anim3D > zeus > m3zume > synloc > synex > metasyn > obliqrt > obliqparse > obliqprint > obliq > obliqlibemb > obliqlibm3 > obliqlibui > obliqlibanim > obliqsrvstd > obliqsrvui > obliqbinmin > obliqbinstd > obliqbinui > obliqbinanim > visualobliq > vocgi > voquery > vorun > webvbt > recordheap > rehearsecode > replayheap > showheap > shownew > showthread > juno-2/juno-app/pkl-fonts > juno-2/juno-machine > juno-2/juno-compiler > juno-2/juno-app > cube > calculator > fisheye > mentor > ---END-of-List--- > > > Packages in Group="gui": > ------------------------------------------------------------------------------ > import-libs > tcp > X11R4 > ui > vbtkit > cmvbt > jvideo > videovbt > formsvbtpixmaps > formsvbt > formsview > formsedit > opengl > webvbt > kate > m3-ui/bicycle > ---END-of-List--- > > > Packages in Group="comm": > ------------------------------------------------------------------------------ > import-libs > tcp > udp > m3tk-misc > tapi > serial > m3tk > netobj > netobjd > stubgen > ---END-of-List--- > > > Packages in Group="caltech-parser": > ------------------------------------------------------------------------------ > import-libs > cit_common > m3tmplhack > cit_util > term > paneman > paneman/kemacs > drawcontext > drawcontext/dcpane > drawcontext/kgv > hack > m3browserhack > parserlib/ktoklib > parserlib/klexlib > parserlib/kyacclib > parserlib/ktok > parserlib/klex > parserlib/kyacc > parserlib/kext > parserlib/parserlib > parserlib/parserlib/test > ---END-of-List--- > > > Packages in Group="m3gnudevtool": > ------------------------------------------------------------------------------ > m3cc > m3gdb > ---END-of-List--- > > > Packages in Group="devlib": > ------------------------------------------------------------------------------ > windowsResources > udp > libsio > libbuf > debug > listfuncs > m3tk-misc > binIO > commandrw > tapi > serial > m3tk > m3scan > m3markup > events > rdwr > deepcopy > sgml > ---END-of-List--- > > > Packages in Group="tool": > ------------------------------------------------------------------------------ > m3staloneback > m3cgcat > m3cggen > fix_nl > libdump > cmpdir > cmpfp > dirfp > uniq > ---END-of-List--- > > > Packages in Group="m3gdb": > ------------------------------------------------------------------------------ > m3gdb > ---END-of-List--- > > > Packages in Group="math": > ------------------------------------------------------------------------------ > arithmetic > unittest-numeric > ---END-of-List--- > > > Packages in Group="m3devtool": > ------------------------------------------------------------------------------ > cm3ide > m3totex > m3tohtml > m3browser > netobj > netobjd > stubgen > sharedobj > sharedobjgen > stablegen > stable > formsview > formsedit > recordheap > rehearsecode > replayheap > showheap > shownew > showthread > pp > ---END-of-List--- > > > Packages in Group="obliq": > ------------------------------------------------------------------------------ > embutils > synloc > synex > metasyn > obliqrt > obliqparse > obliqprint > obliq > obliqlibemb > obliqlibm3 > obliqlibui > obliqlibanim > obliqsrvstd > obliqsrvui > obliqbinmin > obliqbinstd > obliqbinui > obliqbinanim > obliqlib3D > visualobliq > vocgi > voquery > vorun > ---END-of-List--- > > > Packages in Group="webdev": > ------------------------------------------------------------------------------ > http > m3-www/web > m3-www/proxy > webvbt > deckscape > webscape > webcat > ---END-of-List--- > > > Packages in Group="database": > ------------------------------------------------------------------------------ > odbc > postgres95 > db > smalldb > ---END-of-List--- > > > Packages in Group="anim": > ------------------------------------------------------------------------------ > codeview > mg > mgkit > anim3D > zeus > m3zume > mentor > ---END-of-List--- > > > Packages in Group="cvsup": > ------------------------------------------------------------------------------ > cvsup/suplib > cvsup/client > cvsup/server > cvsup/cvpasswd > ---END-of-List--- > > > Packages in Group="juno": > ------------------------------------------------------------------------------ > juno-2/juno-app/pkl-fonts > juno-2/juno-machine > juno-2/juno-compiler > juno-2/juno-app > ---END-of-List--- > > > Packages in Group="demo": > ------------------------------------------------------------------------------ > cube > calculator > fisheye > ---END-of-List--- > > > Packages in Group="game": > ------------------------------------------------------------------------------ > m3-games/badbricks > m3-games/columns > m3-games/fours > m3-games/maze > m3-games/solitaire > m3-games/tetris > ---END-of-List--- > > ===END do-cm3=== > > C:\cm3\Sandbox\scripts\win> > > > > > Regards, > > Randy Coleburn From rodney.m.bates at cox.net Thu Jul 30 03:57:42 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 29 Jul 2009 20:57:42 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: Message-ID: <4A70FE16.4080803@cox.net> Jay K wrote: > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record. Otherwise, the language would allow > a compiler to actually allocate more than the BITS 32 for a value of > type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > Transitive unusedness (boy, did that blow my email client spell checker's brains!) is a bigger issue than this example shows. There could be a large collection of identifiers that cyclically use each other, but no reference to the set from outside. For example, 35 mutually recursive, top-down parsing procedures that all call each other, but somebody forgot the base call to procedure "Program". Would we really want them all to come up unused, as well as everything declared inside any of them? It would take something like a strongly-connected graph components algorithm or such in the compiler. > > > - Jay > From rodney.m.bates at cox.net Thu Jul 30 03:48:36 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 29 Jul 2009 20:48:36 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: Message-ID: <4A70FBF4.9000806@cox.net> There is more wrong with this code than unused warnings. From 2.2.5 Packed types: "variables of type T that occur in records, objects, or arrays will occupy exactly n bits and be packed adjacent to the preceding field or element". (here, type T is BITS n FOR Base). The packed type has no effect when variables of T are not so enclosed. And the Int32Rec is nowhere enclosed in a record, object, or array. Perhaps the BITS 32 FOR should be moved inside the record and applied to the type of field v? Jay K wrote: > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record. Otherwise, the language would allow > a compiler to actually allocate more than the BITS 32 for a value of > type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > > > - Jay > From wagner at elegosoft.com Thu Jul 30 08:40:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 08:40:13 +0200 Subject: [M3devel] C compilation on Windows fails Message-ID: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Trying the first builds on our new Windows VM (still without Hudson), the first stop is: new source -> compiling hand.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\Common\\hand.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\Common\hand.c new source -> compiling dtoa.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\little-endian\\dtoa.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\little-endian\dtoa.c new source -> compiling libgcc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\libgcc\\libgcc.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\libgcc\libgcc.c new source -> compiling RTLinkerC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\common\\RTLinkerC.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\common\RTLinkerC.c new source -> compiling RTOSc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\WIN32\\RTOSc.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\ex_frame\\RTStackC.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\ex_frame\RTStackC.c new source -> compiling ThreadWin32C.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WIN32\\ThreadWin32C.c compile_c => 1073742133 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c compile_c => 1073742133 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c compile_c => 1073742133 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CerrnoC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CerrnoC.c compile_c => 1073742133 C compiler failed compiling: ..\src\C\Common\CerrnoC.c new source -> compiling CstdioC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c compile_c => 1073742133 C compiler failed compiling: ..\src\C\Common\CstdioC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling ThreadInternal.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** Why does the compiler always return 1073742133? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 09:26:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 07:26:42 +0000 Subject: [M3devel] unused warning isn't transitive In-Reply-To: <4A70FBF4.9000806@cox.net> References: <4A70FBF4.9000806@cox.net> Message-ID: 1) I was guessing inappropriately when I added BITS 32. I'll remove it. 2) I understand the need to have exactly sized types, certainly. I don't understand Modula-3's features here. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 20:48:36 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] unused warning isn't transitive > > There is more wrong with this code than unused warnings. > From 2.2.5 Packed types: "variables of type T that occur in > records, objects, or arrays will occupy exactly n bits and be > packed adjacent to the preceding field or element". > (here, type T is BITS n FOR Base). > > The packed type has no effect when variables of T are not > so enclosed. And the Int32Rec is nowhere enclosed in a > record, object, or array. Perhaps the BITS 32 FOR should be > moved inside the record and applied to the type of field v? > > > Jay K wrote: >> TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; >> (* We need v to be inside a record. Otherwise, the language would allow >> a compiler to actually allocate more than the BITS 32 for a value of >> type Swap.Int32. >> *) >> VAR Int32RecVar : Int32Rec; >> VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); >> >> >> Compiler complains that CheckInt32 isn't used. >> It should also perhaps mention Int32RecVar therefore. >> >> >> - Jay >> > From jay.krell at cornell.edu Thu Jul 30 09:32:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 07:32:51 +0000 Subject: [M3devel] C compilation on Windows fails In-Reply-To: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> References: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Message-ID: Peel the onion. cl Should print a banner and very short usage. If that works: echo.> foo.c cl -c foo.c echo %errorlevel% If that works: echo int main(){return 0;}> foo.c cl foo.c echo %errorlevel% .\foo.exe If that works, take a big step: cd wherever\m3-libs\m3core\NT386 cl -nologo -c ..\src\Csupport\Common\hand.c If that fails for lack of -I switches, add them as necessary. Add back the other switches. They are all reliable. - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 08:40:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] C compilation on Windows fails > > Trying the first builds on our new Windows VM (still without Hudson), > the first stop is: > > new source -> compiling hand.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\Common\\hand.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\Common\hand.c > new source -> compiling dtoa.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\little-endian\\dtoa.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\little-endian\dtoa.c > new source -> compiling libgcc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\libgcc\\libgcc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\libgcc\libgcc.c > new source -> compiling RTLinkerC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\common\\RTLinkerC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\common\RTLinkerC.c > new source -> compiling RTOSc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\WIN32\\RTOSc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c > new source -> compiling RTStackC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\ex_frame\\RTStackC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\ex_frame\RTStackC.c > new source -> compiling ThreadWin32C.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WIN32\\ThreadWin32C.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c > new source -> compiling WinNTc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\win32\WinNTc.c > new source -> compiling WinUserC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\win32\WinUserC.c > new source -> compiling CerrnoC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CerrnoC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\C\Common\CerrnoC.c > new source -> compiling CstdioC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\C\Common\CstdioC.c > new exporters -> recompiling RTHooks.i3 > new exporters -> recompiling RTAllocCnts.i3 > new exporters -> recompiling RTHeapRep.i3 > new exporters -> recompiling RTCollectorSRC.i3 > new exporters -> recompiling RTWeakRef.i3 > new exporters -> recompiling RTException.i3 > new exporters -> recompiling RTModule.i3 > new exporters -> recompiling RTProcedureSRC.i3 > new exporters -> recompiling RTTypeSRC.i3 > new exporters -> recompiling RTOS.i3 > new exporters -> recompiling Thread.i3 > new exporters -> recompiling Scheduler.i3 > new exporters -> recompiling ThreadF.i3 > new exporters -> recompiling ThreadInternal.i3 > new exporters -> recompiling Tick.i3 > new exporters -> recompiling Date.i3 > new exporters -> recompiling Text.i3 > compilation failed => not building library "m3core.lib" > Fatal Error: package build failed > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > Why does the compiler always return 1073742133? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 30 09:54:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 09:54:22 +0200 Subject: [M3devel] C compilation on Windows fails In-Reply-To: References: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Message-ID: <20090730095422.57hmgjn5ycocssog@mail.elegosoft.com> Quoting Jay K : > Peel the onion. > cl > > Should print a banner and very short usage. > If that works: > > echo.> foo.c > cl -c foo.c > echo %errorlevel% > > If that works: > > echo int main(){return 0;}> foo.c > cl foo.c > echo %errorlevel% > .\foo.exe > > If that works, take a big step: > > cd wherever\m3-libs\m3core\NT386 > cl -nologo -c ..\src\Csupport\Common\hand.c > If that fails for lack of -I switches, add them as necessary. > Add back the other switches. They are all reliable. OK. Will try that tonight (in about 10 hours -- just arrived at work)... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 10:12:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 08:12:21 +0000 Subject: [M3devel] NetBSD 5.0? Message-ID: I assume nobody cares if support for NetBSD prior to 5.0 is dropped? 5.0 was released April 29, 2009 and supports $ORIGIN. This doesn't mean much anyway, in that supporting additional systems is usually not difficult. - Jay From rodney.m.bates at cox.net Thu Jul 30 15:23:03 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 30 Jul 2009 08:23:03 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: <4A70FBF4.9000806@cox.net> Message-ID: <4A719EB7.4010500@cox.net> Jay K wrote: > 1) I was guessing inappropriately when I added BITS 32. I'll remove it. > I didn't realize you had recently added this. Wasn't there something similar from earlier? > 2) I understand the need to have exactly sized types, certainly. I don't understand Modula-3's features here. > Modula-3 packed types are often not well understood. The language is more-abstract/higher-level than many languages, and this is unfamiliar. Some things that seem to be frequently missed: 1) Packed types have no effect on the set of values representable. That comes strictly from the base type, which is the abstract part. Packed types can only force the compiler neither to allocate padding nor more bits than needed by the value set of the base type. 2) Packed types have an effect only when used as the type of a field of a record or object or as the type of elements of an array. Declaring a whole variable of a packed type doesn't do anything different from declaring it to have the base type. (Except, there are some losses to assignability, e.g., you can't directly assign between two different packed types that have the same base type.) > > > - Jay > > > > > ---------------------------------------- > >> Date: Wed, 29 Jul 2009 20:48:36 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] unused warning isn't transitive >> >> There is more wrong with this code than unused warnings. >> From 2.2.5 Packed types: "variables of type T that occur in >> records, objects, or arrays will occupy exactly n bits and be >> packed adjacent to the preceding field or element". >> (here, type T is BITS n FOR Base). >> >> The packed type has no effect when variables of T are not >> so enclosed. And the Int32Rec is nowhere enclosed in a >> record, object, or array. Perhaps the BITS 32 FOR should be >> moved inside the record and applied to the type of field v? >> >> >> Jay K wrote: >> >>> TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; >>> (* We need v to be inside a record. Otherwise, the language would allow >>> a compiler to actually allocate more than the BITS 32 for a value of >>> type Swap.Int32. >>> *) >>> VAR Int32RecVar : Int32Rec; >>> VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); >>> >>> >>> Compiler complains that CheckInt32 isn't used. >>> It should also perhaps mention Int32RecVar therefore. >>> >>> >>> - Jay >>> >>> From eiserlohpp at yahoo.com Thu Jul 30 18:15:42 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 30 Jul 2009 09:15:42 -0700 (PDT) Subject: [M3devel] m3cc build broken In-Reply-To: Message-ID: <939290.13563.qm@web56801.mail.re3.yahoo.com> The following does look broken. Remember the backslash is an escape character. So you are escaping the ";" delimitor. You need to escape the backslash. > +++ sed -e 's;/;\;g' > sed: -e expression #1, char 7: unterminated `s' command Try: sed -e 's;/;\\;g' +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Thu Jul 30 18:30:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 18:30:50 +0200 Subject: [M3devel] cl on windows Message-ID: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> kind of consistent user interface: elego at wagner ~/work/cm3 $ type cl cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) elego at wagner ~/work/cm3 $ cl elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -version elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -help elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl /help elego at wagner ~/work/cm3 $ echo $? 53 Can it do something else? Visual Studio Setup completely broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 18:33:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 18:33:29 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: <939290.13563.qm@web56801.mail.re3.yahoo.com> References: <939290.13563.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090730183329.mpy2y22tcwo008cw@mail.elegosoft.com> Quoting Peter Eiserloh : > The following does look broken. Remember the backslash is > an escape character. So you are escaping the ";" delimitor. > You need to escape the backslash. > >> +++ sed -e 's;/;\;g' >> sed: -e expression #1, char 7: unterminated `s' command > > Try: > sed -e 's;/;\\;g' It was escaped in the source, but the `fix' to remove $() broke it again: echo 'REM ---BEGIN---' echo '@echo off' printf 'for %%%%p in (' for p in ${PKGS}; do - pw=$(echo $p | sed -e 's;/;\\;g') + pw="`echo $p | sed -e 's;/;\\;g'`" printf "%s; " ${pw} done echo ') do call :ShipIt %%p' It was even tested before. Now it's completely removed, as Jay says forward slashes will just work everywhere. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Thu Jul 30 18:33:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 30 Jul 2009 09:33:58 -0700 (PDT) Subject: [M3devel] Web page experimental colors In-Reply-To: Message-ID: <442486.20009.qm@web56806.mail.re3.yahoo.com> Hi Olaf, www.eiserloh.org is my personal machine, on which I do most of my personal stuff. I have been putting things on its web server so other people can get to those public items I have made. I will probably have to get an account on birch or something. Speaking of debian packages, I am building a virtual machine for ARM_LINUX using qemu. Currently installing Debian Lenny in it. Inside which I will build set of CM3 debian packages for ARM. Following that: PPC_LINUX. Now if I could only get my "nslu2" up and running again. :-) Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Wed, 7/29/09, m3devel-request at elegosoft.com wrote: > From: m3devel-request at elegosoft.com > Subject: M3devel Digest, Vol 33, Issue 113 > To: m3devel at elegosoft.com > Date: Wednesday, July 29, 2009, 12:23 PM > Send M3devel mailing list submissions > to > ??? m3devel at elegosoft.com > > To subscribe or unsubscribe via the World Wide Web, visit > ??? https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > or, via email, send a message with subject or body 'help' > to > ??? m3devel-request at elegosoft.com > > You can reach the person managing the list at > ??? m3devel-owner at elegosoft.com > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of M3devel digest..." > > > Today's Topics: > > ???1. Re: M3devel Digest, Vol 33, Issue 104 > (Olaf Wagner) > ???2. unused warning isn't transitive (Jay > K) > ???3. Re: update on NT386 build (Windows XP, > VC 2008) (Jay K) > ???4. m3cc build broken (Olaf Wagner) > ???5. Re: m3cc build broken (Jay K) > ???6. Re: m3cc build broken (Olaf Wagner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Jul 2009 14:27:27 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 104 > To: m3devel at elegosoft.com > Message-ID: <20090729142727.296t56l5u9wc0sg8 at mail.elegosoft.com> > Content-Type: text/plain;??? > charset=UTF-8;??? > DelSp="Yes";??? format="flowed" > > Hi Peter, > > thanks for your encouragement. > Regression builds look much better today, I think we may > be > able to have RC2 packages at the weekend. Though I'll have > to attend > to some other business then, too, like mawing the lawn in > the > garden ;-) > > I hope I'll find the time to work on your suggestions for > the > web presentation then, too. > > As for the Debian packages you've built, we should > definitely > link them on the release pages. But I doubt that I'll have > time > to test them. I trust that others will do that before the > release > though. Will your web server be able to manage several > downloads, > or should we copy them over to birch (which is usually > heavily > loaded most of the time), too? > > Olaf > > Quoting Peter Eiserloh : > > > Hi Olaf, > > > > I just wanted to say thank you!? You have been > doing a > > great job.???A compiler and development > environment such > > as CM3 is a very large software suite, and to > coordinate > > a software release is never an easy job. > > > > Sure the web pages can use some sprucing up, big > deal! > > Like you said, all the web pages are in the CVS repo, > any > > one with write access to the repo could change them. > > > > It may seem like there is a lot of complaining, and it > is, > > but what has everyone jazzed up at the moment (okay > last > > few months), is that shortly, all the work we have > been > > doing will be seeing a much larger audience, and we > want > > our favorite project to look its best. > > > > What we all should remember is that we all have real > lives, > > away from the computer and modula-3.? None of us > has enough > > time to do _everything_ we want. > > > > BTW: I just wanted bring your attention to my latest > build > > of Debian packages for AMD64_LINUX on "lenny".? I > built it > > today from > cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. > > > >? ? http://www.eiserloh.org/mirrors/modula3/ > > > > If you have a Debian-lenn-AM64 machine, could you try > it > > out.? Maybe, even download the source package, > and try > > building it yourself.? The source package should > work with > > any architecture supported by Debian. > > > > Please comment on any improvements I can make to > these > > debian packages. > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? | > > > +--------------------------------------------------------+ > > > >> Date: Mon, 27 Jul 2009 22:49:26 +0200 > >> From: Olaf Wagner > >> Subject: Re: [M3devel] bad web pages > >? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? It will also be the > >> last time that I coordinate a CM3 release. > Everyone around > >> me is already complaining :-( > >> > >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Jul 2009 17:42:22 +0000 > From: Jay K > Subject: [M3devel] unused warning isn't transitive > To: m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record.? Otherwise, the > language would allow > ???a compiler to actually allocate more than > the BITS 32 for a value of > ???type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - > ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > > > - Jay > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jul 2009 18:18:30 +0000 > From: Jay K > Subject: Re: [M3devel] update on NT386 build (Windows XP, > VC 2008) > To: > Cc: m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > (formatting possibly all messed up sorry) > > > --- processing package "m3-sys\cm3" --- --- building in > NT386 --- ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > This is arguably a failing of your .cmd. The other > .sh/.py/.cmd define these. > Perhaps we should always do it in the m3makefile, nowhere > else, and don't warn? > Or maybe it is supposed to be fixed for the entire build? > Or maybe Olaf just likes to write non portable .sh, in > scripts, instead of in m3makefile? > (where he can still write non portable .sh, but I have to > port it, either way, difference is whether or not it gets > written twice or four times, > twice is Posix and Win32 in m3makefile, four times is > Olaf's .sh, my .py, possibly maybe my .cmd, and your .cmd) > > > Try the .py. Tell me what errors you get. Please. > > > There are contradictory principles at work here: > ? reduce dependencies > ? don't duplicate work > > > We are duplicating work. And I might continue to -- I might > rewrite more of Olaf's .sh in .py. But my argument is that > it is > then more portable and the duplication can then be stopped. > (Granted there are sticking points, like MIPS64_OPENBSD > possibly and > I386_MSDOS possibly, but sh's portability is also > overstated, e.g. Solaris..) > > > You can try my .cmd too, but I'd really like to know why > the Python doesn't work for you. > The .sh, .py, my .cmd, and indirectly the m3makefile read > the scripts/version file. > Which btw should maybe be at the root? Maybe. It depends on > if you feel "scripts" are "official" or merely > "convenience". > And if "version" is "official" -- don't mix "official" with > "convenience"? Not a big deal. > > > Many of the warnings are in generated code, which is partly > why I've long ignored them. Plus that I'm lazy. > We can try putting in? in the generated code. I just > hope the compiler isn't a stickler > then and complains that sometimes there is nothing to not > warn about (like when you say? but use it; > geez, maybe my intent was, I may or may not use, just shut > up either way?) > > > I'll see what I can do, but none or almost none of this is > Windows specific. Nobody seems to care much. > > > That unaligned thing is different. - I thought it didn't > warn on NT, just others. > It possibly needs to be honored on all. > ? - The Modula-3 language is difficient here in > general. > We need to be able to state alignment if we do want to > "interoperate directly" with external data. > Normally I say "write C wrappers" but this is a file format > not a super cheap little in-memory struct. > We almost need to be able to state alignments higher than > we can today. > > > I've seen stuff like: > setjmp.h: > ? gccism(alignment hgher than Modula-3 allows one to > state) > ? comment(less alignment is ok, but more is better) > > > and Modula-3 uses less. Maybe it is yucky and not ANSI C > but all the compilers have various extensions to finely > control layout. > Either we wrap everything up, or unpack from bytes, or copy > those C features. Roughly speaking. > I'll probably look into "unpack from bytes". > Interfacing with the external world sometimes is ugly > business and that's just tough; you can't change it. > > > - Jay > > > > > > > > > > > > ________________________________ > > From: jay.krell at cornell.edu > > To: rcoleburn at scires.com > > Date: Wed, 29 Jul 2009 04:28:54 -0700 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] update on NT386 build (Windows > XP, VC 2008) > > > > Not bad! > > > > - Jay (phone) > > > > On Jul 29, 2009, at 4:14 AM, "Randy Coleburn"> > wrote: > > > > > > Update on NT386 build (Windows XP, Microsoft Visual > C++ Express 2008), R.Coleburn > > > ===================================================================== > > > > > > Here are the errors and warnings I am seeing currently > in building the minimal installation: > > > > > > > > --- processing package "m3-libs\libm3" --- > > --- building in NT386 --- > > "..\src\pickle\ver2\ConvertPacking.m3", line 170: > warning: not used (CheckInt32) > > 1 warning encountered > > > > > > > > > > > > > > > > Here is a list of all packages that I am building: > > > > > > > > m3-win\import-libs > > m3-sys\m3cc > > m3-libs\m3core > > m3-libs\libm3 > > m3-sys\windowsResources > > m3-libs\patternmatching > > m3-libs\sysutils > > m3-libs\unittest > > m3-sys\m3middle > > m3-sys\m3objfile > > m3-sys\m3linker > > m3-sys\m3back > > m3-sys\m3staloneback > > m3-sys\m3front > > m3-sys\m3quake > > m3-sys\cm3 > > m3-sys\m3scanner > > m3-sys\m3tools > > m3-sys\m3cgcat > > m3-sys\m3cggen > > m3-sys\m3gdb > > m3-tools\m3bundle > > m3-sys\mklib > > m3-sys\fix_nl > > m3-sys\libdump > > m3-libs\arithmetic > > m3-libs\unittest-numeric > > m3-libs\bitvector > > m3-libs\digraph > > m3-libs\parseparams > > m3-libs\realgeometry > > m3-libs\set > > m3-libs\slisp > > m3-libs\sortedtableextras > > m3-libs\table-list > > m3-libs\tempfiles > > m3-libs\tcl > > m3-comm\tcp > > m3-sys\cm3ide > > m3-comm\udp > > m3-libs\libsio > > m3-libs\libbuf > > m3-libs\debug > > m3-libs\listfuncs > > m3-libs\embutils > > m3-libs\m3tk-misc > > m3-www\http > > m3-libs\binIO > > m3-libs\commandrw > > m3-comm\tapi > > m3-comm\serial > > m3-tools\m3tk > > m3-tools\mtex > > m3-tools\m3totex > > m3-tools\m3tohtml > > m3-tools\m3scan > > m3-tools\m3markup > > m3-tools\m3browser > > m3-tools\cmpdir > > m3-tools\cmpfp > > m3-tools\dirfp > > m3-tools\uniq > > m3-comm\netobj > > m3-comm\netobjd > > m3-comm\stubgen > > m3-comm\events > > m3-comm\rdwr > > m3-comm\sharedobj > > m3-comm\sharedobjgen > > m3-db\odbc > > m3-db\postgres95 > > m3-db\db > > m3-db\smalldb > > m3-db\stablegen > > m3-db\stable > > m3-ui\X11R4 > > m3-ui\ui > > m3-ui\PEX > > m3-ui\vbtkit > > m3-ui\cmvbt > > m3-ui\jvideo > > m3-ui\videovbt > > m3-www\web > > m3-www\proxy > > m3-ui\formsvbtpixmaps > > m3-ui\formsvbt > > m3-ui\formsview > > m3-ui\formsedit > > m3-ui\codeview > > m3-tools\cvsup\suplib > > m3-tools\cvsup\client > > m3-tools\cvsup\server > > m3-tools\cvsup\cvpasswd > > m3-ui\mg > > m3-ui\mgkit > > m3-ui\opengl > > m3-ui\anim3D > > m3-ui\zeus > > m3-ui\m3zume > > m3-obliq\synloc > > m3-obliq\synex > > m3-obliq\metasyn > > m3-obliq\obliqrt > > m3-obliq\obliqparse > > m3-obliq\obliqprint > > m3-obliq\obliq > > m3-obliq\obliqlibemb > > m3-obliq\obliqlibm3 > > m3-obliq\obliqlibui > > m3-obliq\obliqlibanim > > m3-obliq\obliqsrvstd > > m3-obliq\obliqsrvui > > m3-obliq\obliqbinmin > > m3-obliq\obliqbinstd > > m3-obliq\obliqbinui > > m3-obliq\obliqbinanim > > m3-obliq\obliqlib3D > > m3-obliq\visualobliq > > m3-obliq\vocgi > > m3-obliq\voquery > > m3-obliq\vorun > > m3-ui\webvbt > > m3-tools\recordheap > > m3-tools\rehearsecode > > m3-tools\replayheap > > m3-tools\showheap > > m3-tools\shownew > > m3-tools\showthread > > m3-ui\juno-2\juno-app\pkl-fonts > > m3-ui\juno-2\juno-machine > > m3-ui\juno-2\juno-compiler > > m3-ui\juno-2\juno-app > > m3-demo\cube > > m3-demo\calculator > > m3-demo\fisheye > > m3-demo\mentor > > caltech-parser\cit_common > > caltech-parser\m3tmplhack > > caltech-parser\cit_util > > caltech-parser\term > > m3-libs\deepcopy > > caltech-parser\paneman > > caltech-parser\paneman\kemacs > > caltech-parser\drawcontext > > caltech-parser\drawcontext\dcpane > > caltech-parser\drawcontext\kgv > > caltech-parser\hack > > caltech-parser\m3browserhack > > caltech-parser\parserlib\ktoklib > > caltech-parser\parserlib\klexlib > > caltech-parser\parserlib\kyacclib > > caltech-parser\parserlib\ktok > > caltech-parser\parserlib\klex > > caltech-parser\parserlib\kyacc > > caltech-parser\parserlib\kext > > caltech-parser\parserlib\parserlib > > caltech-parser\parserlib\parserlib\test > > m3-tools\pp > > m3-tools\kate > > m3-libs\sgml > > m3-www\deckscape > > m3-www\webscape > > m3-www\webcat > > m3-ui\bicycle > > m3-games\badbricks > > m3-games\columns > > m3-games\fours > > m3-games\maze > > m3-games\solitaire > > m3-games\tetris > > ---END-of-List--- > > > > > > > > > > > > > > > > Here are the errors and warnings I am seeing currently > in building all the packages listed above: > > > > > > > > --- processing package "m3-sys\m3cc" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MA > > KEINFO=: ../gcc/configure -srcdir=../gcc > -disable-bootstrap -disable-intl -di > > sable-libgomp -disable-libmudflap -disable-libssp > -disable-nls -enable-languages > > =m3cg -enable-targets=all -disable-dependency-tracking > -disable-fixincludes -dis > > able-libgcc -disable-decimal-float > -disable-fixed-point | tee -a C:/cm3/Sandbox > > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > > 'chmod' is not recognized as an internal or external > command, > > operable program or batch file. > > 'sh' is not recognized as an internal or external > command, > > operable program or batch file. > > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line > 385: quake runtime error: > > exit 1: sh -ec ./_m3000.sh > > --procedure-- -line- -file--- > > exec -- > > m3cc_Run 385 > C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > > include_dir 514 > C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args > > Fatal Error: package build failed > > > > > > > > > > --- processing package "m3-libs\libm3" --- > > --- building in NT386 --- > > "..\src\pickle\ver2\ConvertPacking.m3", line 170: > warning: not used (CheckInt32) > > 1 warning encountered > > > > > > > > > > --- processing package "m3-sys\cm3" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > missing CM3_VERSION_NUMBER will read version file > > missing CM3_VERSION_TEXT will read version file > > missing CM3_LAST_CHANGED will read version file > > > > > > > > > > --- processing package "m3-sys\m3gdb" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-sys\mklib" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling Main.m3 > > "..\src\Main.m3", line 28: warning: unrecognized > pragma (ignored) (UNALIGNED) > > 1 warning encountered > > > > > > > > > > --- processing package "m3-db\postgres95" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-ui\X11R4" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-ui\PEX" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-tools\cvsup\suplib" --- > > --- processing package "m3-tools\cvsup\client" --- > > --- processing package "m3-tools\cvsup\server" --- > > --- processing package "m3-tools\cvsup\cvpasswd" --- > > nothing attempts to build for these packages > > > > > > > > > > --- processing package "m3-ui\anim3D" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling Win_OpenGL_Base.m3 > > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: > warning: exception is never raised: GraphicsBase.Failure > > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: > warning: potentially unhandled exception: > GraphicsBase.Failure > > 2 warnings encountered > > > > > > > > > > --- processing package "m3-obliq\obliqrt" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling ObValueCB.i3 > > "..\NT386\ObValueCB.i3", line 9: warning: not used > (ObValueRep) > > 1 warning encountered > > new source -> compiling ObValueCBProxy.i3 > > "..\NT386\ObValueCBProxy.i3", line 9: warning: not > used (ObValueRep) > > 1 warning encountered > > new source -> compiling ObValueSO.m3 > > "..\NT386\ObValueSO.m3", line 12: warning: not used > (AtomList) > > 1 warning encountered > > new exporters -> recompiling ObValueCBProxy.i3 > > "..\NT386\ObValueCBProxy.i3", line 9: warning: not > used (ObValueRep) > > 1 warning encountered > > > > > > > > > > --- processing package "caltech-parser\cit_common" > --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > unsupported m3_option value: "-X2 at -pg@" > > unsupported m3_option value: "-g" > > > > > > > > > > --- processing package "m3-libs\deepcopy" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling DeepCopy.m3 > > "..\src\DeepCopy.m3", line 56: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > > "..\src\DeepCopy.m3", line 61: warning: potentially > unhandled exception: > > "..\src\DeepCopy.m3", line 97: warning: exception is > never raised: > > 3 warnings encountered > > > > > > > > > > --- processing package > "caltech-parser\parserlib\klexlib" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RegExpTok.m3 > > "..\NT386\RegExpTok.m3", line 41: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > > 1 warning encountered > > > > > > > > > > --- processing package > "caltech-parser\parserlib\parserlib\test" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok > ..\src\Calc.t -o CalcTok.i3 > > The system cannot find the path specified. > > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: > quake runtime error: exit 1: > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok > ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > > exec -- > > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > > include_dir 4 > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > > 4 > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > > > > > > > > > --- processing package "m3-tools\pp" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-tools\kate" --- > > --- building in NT386 --- > > KDESHARE not found; please define it! > > > > > > > > > > Regards, > > > > Randy Coleburn > > > > ------------------------------ > > Message: 4 > Date: Wed, 29 Jul 2009 20:34:25 +0200 > From: Olaf Wagner > Subject: [M3devel] m3cc build broken > To: m3devel at elegosoft.com > Message-ID: <20090729203425.wq5rkzvdc8gc8o88 at mail.elegosoft.com> > Content-Type: text/plain; charset=ISO-8859-15; > DelSp="Yes"; > ??? format="flowed" > > It looks as if the m3cc builds have broken after the last > commit to the release branch: > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > error: > ignoring ../src/m3overrides > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", > line 292: quake runtime error: undefined variable:? > build_dir > > --procedure--? -line-? -file--- > m3cc_Run? ? ? ? ? > 292??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > include_dir? ? > ???485??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > ? ? ? ? ? ? ? ? > ? ???4??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > What's going on there? Why is build_dir suddenly > undefined? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 5 > Date: Wed, 29 Jul 2009 19:12:54 +0000 > From: Jay K > Subject: Re: [M3devel] m3cc build broken > To: Olaf , > m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > sorry, fixed now, agreed it is odd, I don't understand, > undid my simple seeming change > > - Jay > > > ---------------------------------------- > > Date: Wed, 29 Jul 2009 20:34:25 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3cc build broken > > > > It looks as if the m3cc builds have broken after the > last > > commit to the release branch: > > > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > > > error: > > ignoring ../src/m3overrides > > > > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", > line 292: quake runtime error: undefined variable: > > build_dir > > > > --procedure-- -line- -file--- > > m3cc_Run 292 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > > include_dir 485 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > > 4 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > What's going on there? Why is build_dir suddenly > undefined? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner > | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 6 > Date: Wed, 29 Jul 2009 21:23:39 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] m3cc build broken > To: Jay K > Cc: m3devel > Message-ID: <20090729212339.q3a9jlwty8oc0ksk at mail.elegosoft.com> > Content-Type: text/plain;??? > charset=UTF-8;??? > DelSp="Yes";??? format="flowed" > > Quoting Jay K : > > > sorry, fixed now, agreed it is odd, I don't > understand, undid my??? > > simple seeming change > > Never mind. The make-dist.sh script seems to be broken, > too. > Have a look at the end of? > http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. > > I guess I'll postpone package build again... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > End of M3devel Digest, Vol 33, Issue 113 > **************************************** > From rcoleburn at scires.com Thu Jul 30 18:57:38 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 12:57:38 -0400 Subject: [M3devel] cl on windows In-Reply-To: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> Message-ID: <4A719845.1E75.00D7.1@scires.com> Olaf: I don't think you want to be doing this with cygwin. That would mean you are executing in a cygwin environment, not a true Windows-only environment. For the Visual Studio command line to work, you have to run the script that sets up the environment variables. From the Windows Start menu, there should be a menu tree labeled "Visual C++ 9.0 Express Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". Choosing this item from the menu will bring up a command prompt with the environment set up properly. Alternately, you can run the following command from an existing command prompt window: "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat x86" Note that the above command line assumes you have installed Visual C++ 2008 Express Edition. The paths may be different for different versions of the software. Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or cm3SetupCmdEnv.CMD), they do this all for you. Regards, Randy Coleburn >>> Olaf Wagner 7/30/2009 12:30 PM >>> kind of consistent user interface: elego at wagner ~/work/cm3 $ type cl cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) elego at wagner ~/work/cm3 $ cl elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -version elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -help elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl /help elego at wagner ~/work/cm3 $ echo $? 53 Can it do something else? Visual Studio Setup completely broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 30 19:23:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 19:23:56 +0200 Subject: [M3devel] cl on windows In-Reply-To: <4A719845.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Thanks for the answer, Randy. I had just remembered that I needed to set a number of variables. Attached is the shell script I came up with. Compilation works now without a problem. I get as far as linking: new source -> compiling WinUserC.c -> archiving m3core.lib link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 9 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** This seems to be a problem in the cm3 configuration files, right? More evidence: elego at wagner ~/work/cm3 $ (cd m3-libs/m3core; cm3 -commands -build -keep) --- building in NT386 --- cd NT386 ignoring ..\src\m3overrides rm .M3SHIP rm .M3OVERRIDES inhale m3core.m3x -> archiving m3core.lib rm m3core.lib rm m3core.lib rm m3core.lib.sa rm m3core.dll rm m3core.def rm m3core.lst rm m3core.dll.manifest rm m3core.pdb rm _m3responsefile0.txt rm _m3responsefile1.txt rm m3core.ilk rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk mklib @_m3responsefile0.txt 2>&1 > m3core.lst rm m3core.lib rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk link @_m3responsefile1.txt 2>&1 > m3core.lst link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 6 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. cd .. elego at wagner ~/work/cm3 $ cat m3-libs/m3core/NT386/_m3responsefile1.txt -nodefaultlib -debug -incremental:no -opt:ref -delayload:wsock32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll delayimp.lib -def:m3core.def -dll -out:m3core.dll -noentry hand.obj dtoa.obj libgcc.obj RTHooks.io RTHooks.mo [...lots of objects removed...] kernel32.lib msvcrt.lib Olaf PS: I don't think that just returning 53 is the correct way to remind users that some environment settings are missing though :-) Quoting Randy Coleburn : > Olaf: > > I don't think you want to be doing this with cygwin. That would mean > you are executing in a cygwin environment, not a true Windows-only > environment. > > For the Visual Studio command line to work, you have to run the script > that sets up the environment variables. From the Windows Start menu, > there should be a menu tree labeled "Visual C++ 9.0 Express > Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". > Choosing this item from the menu will bring up a command prompt with the > environment set up properly. > > Alternately, you can run the following command from an existing command > prompt window: "C:\Program Files\Microsoft Visual Studio > 9.0\VC\vcvarsall.bat x86" > > Note that the above command line assumes you have installed Visual C++ > 2008 Express Edition. The paths may be different for different versions > of the software. > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or > cm3SetupCmdEnv.CMD), they do this all for you. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 19:27:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 19:27:08 +0200 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <20090730192708.n77rrx3ta80ws88w@mail.elegosoft.com> Quoting Olaf Wagner : > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up with. Just in case somebody actually misses the promised attachment... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- # source me PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/BIN" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools" PATH="$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5" PATH="$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/VCPackages" PATH="$PATH:/cygdrive/c/Program Files//Microsoft SDKs/Windows/v6.0A/bin" PATH="$PATH:/cygdrive/c/WINDOWS/system32" PATH="$PATH:/cygdrive/c/WINDOWS" PATH="$PATH:/cygdrive/c/WINDOWS/System32/Wbem" PATH="$PATH:/cygdrive/c/Program Files/Microsoft SQL Server/90/Tools/binn/" PATH="$PATH:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/V/cygdrive/c/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools" INCLUDE='c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE' LIB='c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\lib;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB' LIBPATH='c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB' VCINSTALLDIR='c:\Program Files\Microsoft Visual Studio 9.0\VC' VSINSTALLDIR='c:\Program Files\Microsoft Visual Studio 9.0' DevEnvDir='c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE' Framework35Version='v3.5' FrameworkDir='c:\WINDOWS\Microsoft.NET\Framework' FrameworkVersion='v2.0.50727' export INCLUDE LIB LIBPATH VCINSTALLDIR VSINSTALLDIR DevEnvDir Framework35Version FrameworkDir FrameworkVersion From rcoleburn at scires.com Thu Jul 30 19:53:23 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 13:53:23 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> Message-ID: <4A71A555.1E75.00D7.1@scires.com> Jay: Your message was truncated, and provided much more info than I think I'm asking about. I simply need to know what packages have to be built, and in what order, to produce the minimal binary distribution for a given platform. In my case right now, platform is Windows XP or Vista. I had assumed, perhaps incorrectly, that "min" defines that set. But, I'm not sure. In particular, it looked like "front" might be building parts of the compiler that are needed. Or am I all wrong here, and rebuilding the compiler (i.e., using an old compiler to build a new version of itself) is a different process from building the minimal binary distribution? I also provided in my email a listing of all the group tags and the packages in each group for everyone's reference. (Sort of a sanity check on the correctness of PkgInfo.txt.) So, let me ask a concrete yes/no question, if one wanted to perform a complete cm3 installation on Windows, is the 13-step procedure outlined below correct? If not, please advise on changes needed. 1. Install Visual C++ 2008 Express Edition. 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. 8. mkdir "C:\cm3\bin\config" if it is missing 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". I know you've probably got scripts for all of this, but somewhere we need to document exactly what is required. Scripts are an expression of the requirements and they may contain bugs, so knowing what is supposed to happen, versus reading a script, is important. Regards, Randy >>> Jay K 7/29/2009 8:35 PM >>> I'm only going to answer partially for now.. > Are these really all that is needed > to build the "minimal" binary distribution? It depends on what you mean. The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows). That's it. You don't need any packages at all. You don't need m3core/libm3. I setup tinderbox a few times recently. In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far). What that lets you do is build the whole system, from the bottom of the dependency tree and on up. HISTORICALLY there have been some wrinkles here. And it made pretty good sense, I guess, to draw another line. Whether or not that will happen again, unclear. The specific wrinkles were: - Old compiler could not compile a new libm3, if new targets had been added That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler - Old compiler cannot compile m3core or libm3 that uses LONGINT. Now, I have a suspicion that these issues are not extremely rare but just somewhat rare. All compilation systems written in themselves have a circularity. The compiler depends on the compiler. Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make. Let's imagine, crazy, that all the identifiers were changed to lowercase. If "just" change the compiler, well then, you can't build the compiler. You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form. I feel like I might be missing something though. In any case..what are the scenarios? - People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith. Give these people "std" or a bunch of binary packages. These people, in the extreme impatience form, would not even like Olaf's workspace packages. - People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3. Today you give these people cm3, cm3cg, and config files. But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does. The difference in DEC SRC is that quake was written in C, so the division was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose). - Various (infinite) in between situations such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 30 21:35:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 19:35:13 +0000 Subject: [M3devel] cl on windows In-Reply-To: <4A719845.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: Cygwin is fine. Really. You can mix them. The problem is that both cl.exe and mspdb90.dll need to be in path, and VC link.exe needs to be ahead of Cygwin link.exe, or delete Cygwin link.exe. C:\Users\jay>which cl /cygdrive/c/msdev/90/VC/BIN/cl C:\Users\jay>which gcc /usr/bin/gcc C:\Users\jay>which cvs /usr/bin/cvs C:\Users\jay>gcc -v ... gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) C:\Users\jay>cvs Usage: cvs [cvs-options] command [command-options-and-arguments] ... C:\Users\jay>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] C:\Users\jay>which mspdb80.dll /cygdrive/c/msdev/90/Common7/IDE/mspdb80.dll C:\Users\jay>which link /cygdrive/c/msdev/90/VC/BIN/link - Jay ________________________________ > Date: Thu, 30 Jul 2009 12:57:38 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cl on windows > > > > > > > > Olaf: > > > > I don't think you want to be doing this with cygwin. That would mean you are executing in a cygwin environment, not a true Windows-only environment. > > > > For the Visual Studio command line to work, you have to run the script that sets up the environment variables. From the Windows Start menu, there should be a menu tree labeled "Visual C++ 9.0 Express Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". Choosing this item from the menu will bring up a command prompt with the environment set up properly. > > > > Alternately, you can run the following command from an existing command prompt window: "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat x86" > > > > Note that the above command line assumes you have installed Visual C++ 2008 Express Edition. The paths may be different for different versions of the software. > > > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or cm3SetupCmdEnv.CMD), they do this all for you. > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/30/2009 12:30 PM>>> > kind of consistent user interface: > > elego at wagner ~/work/cm3 > $ type cl > cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) > > elego at wagner ~/work/cm3 > $ cl > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl -version > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl -help > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl /help > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > Can it do something else? > Visual Studio Setup completely broken? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 30 21:48:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 19:48:38 +0000 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. Cygwin's link.exe is a synonym for ln.exe. > Attached is the shell script I came up with. Here are my mine for many environments. Of particular interest are: env\cm3\cm3.cygwin.bat env\cm3\cm3.vc90.bat env\test.bat used to work but I've deleted some of the toolsets You can see a lot of it works via composition. cm3.vc90.bat uses env\ms\vc90.bat - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 19:23:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cl on windows > > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up with. > > Compilation works now without a problem. I get as far as linking: > > new source -> compiling WinUserC.c > -> archiving m3core.lib > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 9 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > This seems to be a problem in the cm3 configuration files, right? > > More evidence: > > elego at wagner ~/work/cm3 > $ (cd m3-libs/m3core; cm3 -commands -build -keep) > --- building in NT386 --- > > cd NT386 > ignoring ..\src\m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale m3core.m3x > > -> archiving m3core.lib > rm m3core.lib > rm m3core.lib > rm m3core.lib.sa > rm m3core.dll > rm m3core.def > rm m3core.lst > rm m3core.dll.manifest > rm m3core.pdb > rm _m3responsefile0.txt > rm _m3responsefile1.txt > rm m3core.ilk > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > mklib @_m3responsefile0.txt 2>&1> m3core.lst > rm m3core.lib > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > link @_m3responsefile1.txt 2>&1> m3core.lst > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 6 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > cd .. > > elego at wagner ~/work/cm3 > $ cat m3-libs/m3core/NT386/_m3responsefile1.txt > -nodefaultlib > -debug > -incremental:no > -opt:ref > -delayload:wsock32.dll > -delayload:advapi32.dll > -delayload:gdi32.dll > -delayload:netapi32.dll > -delayload:user32.dll > -delayload:comctl32.dll > delayimp.lib > -def:m3core.def > -dll > -out:m3core.dll > -noentry > hand.obj > dtoa.obj > libgcc.obj > RTHooks.io > RTHooks.mo > [...lots of objects removed...] > kernel32.lib > msvcrt.lib > > > Olaf > > PS: I don't think that just returning 53 is the correct way to remind > users that some environment settings are missing though :-) > > Quoting Randy Coleburn : > >> Olaf: >> >> I don't think you want to be doing this with cygwin. That would mean >> you are executing in a cygwin environment, not a true Windows-only >> environment. >> >> For the Visual Studio command line to work, you have to run the script >> that sets up the environment variables. From the Windows Start menu, >> there should be a menu tree labeled "Visual C++ 9.0 Express >> Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". >> Choosing this item from the menu will bring up a command prompt with the >> environment set up properly. >> >> Alternately, you can run the following command from an existing command >> prompt window: "C:\Program Files\Microsoft Visual Studio >> 9.0\VC\vcvarsall.bat x86" >> >> Note that the above command line assumes you have installed Visual C++ >> 2008 Express Edition. The paths may be different for different versions >> of the software. >> >> Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or >> cm3SetupCmdEnv.CMD), they do this all for you. >> >> Regards, >> Randy Coleburn > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- A non-text attachment was scrubbed... Name: env.zip Type: application/x-zip-compressed Size: 63495 bytes Desc: not available URL: From jay.krell at cornell.edu Thu Jul 30 22:11:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 20:11:41 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A71A555.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> Message-ID: Randy, the short answer is: Find a goal state in a graph, which you haven't clearly done, walk that graph from the bottom up, and if there are circularities (there are, you need to have cm3 first, before you can build cm3), you need to download prebuilt files from somewhere (cm3 and mklib). Everything else is filling in the details of the goal state, discovering the circularities, and that we have the graph recorded in a redundant fashion in pkginfo.txt. The real data is the m3makefiles. longer answer: Randy, what is a "minimal" distribution? You have't defined the goal. What is "build"? You haven't defined the goal. I could just say: "Whatever you need, to build it, just download it from here." I'll define it as some arbitrary very minimal compiler and runtime set, specifically m3core and libm3. But you can have working Modula-3 programs certainly without libm3. And some Modula-3 programs will have a GUI so will want more libraries. What is "minimal"? And depending on future changes, the steps might change. Or maybe just pkginfo.txt will change. If there is no documentation and there is code, the code is the documentation. A lot of the code is declarative -- you look at the import statements in m3makefile. For given package foo, say "cm3", you walk the list of imports transitively. I'm not sure cm3 actually uses libm3 for example, and maybe it won't in the future. This is a very real point. pkginfo.txt duplicates dependency information by nature of being "in the correct order", but that information is already contained in the m3makefiles. Your questions have made me realize the redundancy we have and that we should fix it. Or, really, older cm3 did not use sysutils, but now it does. Things change. And you haven't really defined the goal. Instead of "walk pkginfo.txt in order", it should be "pick a package you want, say cm3, and build its dependency tree from the bottom up, using the m3makefiles to discover that tree, plus the PKGS file to locate packages". I'm going to make up a goal that might resemble yours and correct your instructions. > 1. Install Visual C++ 2008 Express Edition. ok. Though you don't need all of it by far. You don't need the entire IDE. > > 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. No. You don't need all of it. You only need two files -- cm3.exe and mklib.exe. Other platforms need cm3cg and don't need mklib. Except you never really need cm3cg, it falls out of the instructions -- cm3 can build it. It depends on how much you want to build vs. download. And optionally the config files. You can get them from either the source tree or download them. See, two legitimate places for things -- download from one place or another. > > > 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. No. You don't need all of it. You need, roughly, only m3-libs\m3core, m3-libs\libm3, m3-libs\sysutils, some of m3-sys. m3-sys/m3cc is needed for most platforms, but not the gcc-apple directory, that's only for iphone. > > 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" Not needed. > > 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" Not needed. > > 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. Many ways to do that. > > > 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. Multiple ways to do this but ok. > > > 8. mkdir "C:\cm3\bin\config" if it is missing ok. You can just mkdir unconditionally. > > > 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" You don't need all of it, but ok, that is what I do. > > > 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: > > INSTALL_ROOT = path() & "/.." > > include(path() & "/config/" & HOST) ok > > > 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) No. Well, it depends on the goal. Really. You already have a cm3. "min" gives you m3core and libm3. Combine that with the cm3 you already have and great, you have a slightly larger more useful set of libraries. > > > 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. NOt really. The repitition isn't doing what you say. Look at the group called "front". Which isn't completely accurate since it includes m3cc. Perhaps there should be a group compiler. But really, again, this is cm3 plus its transitive dependencies. I think maybe we need to partly ditch "groups". In paritcular, "groups" should contain useful end results and not their dependencies. m3middle doesn't belong in any group, it is just implied by cm3. Seriously. But the scripts don't currently read m3makefiles. Redoing things in cm3 would be better? > > > 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". Ok. Sort of. > > I know you've probably got scripts for all of this Yep. > Scripts are an expression of the requirements Sometimes it is the other way around. - Jay From wagner at elegosoft.com Thu Jul 30 22:16:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:16:42 +0200 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <442486.20009.qm@web56806.mail.re3.yahoo.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Olaf, > > www.eiserloh.org is my personal machine, on which I do most of my > personal stuff. I have been putting things on its web > server so other people can get to those public items I > have made. > > I will probably have to get an account on birch or something. > > Speaking of debian packages, I am building a virtual machine > for ARM_LINUX using qemu. Currently installing Debian Lenny > in it. Inside which I will build set of CM3 debian packages > for ARM. > > Following that: PPC_LINUX. > > Now if I could only get my "nslu2" up and running again. :-) Everyone known on the m3 mailing lists will easily get an ssh login to birch without problems by just sending a public ssh key to our administrators. You can use that account to commit to the M3 repository, to test and compile on birch (as long as you don't bring the machine down) and to generally look around (M3 web server, tinderbox, Hudson). We can create a staging area for new designs on the web server, too. I can also create logins on the new Hudson server for all those who are interested. Access is simply password restricted there and not really secure though. All that should be described in our web pages, too, but it's probably buried and well hidden :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 22:19:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:19:19 +0200 Subject: [M3devel] cl on windows In-Reply-To: References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: <20090730221919.j5ufrc8qroc4swog@mail.elegosoft.com> Quoting Jay K : > > Cygwin is fine. Really. You can mix them. > The problem is that both cl.exe and mspdb90.dll need to be in path, > and VC link.exe needs to be ahead of Cygwin link.exe, or delete > Cygwin link.exe. Oh my, stupid me! Wrong link command... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 22:30:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:30:37 +0200 Subject: [M3devel] cl on windows In-Reply-To: References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> Quoting Jay K : > Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. > Cygwin's link.exe is a synonym for ln.exe. One step further thanks to your hint. Now dynamic linking fails: Creating library sysutils.lib and object sysutils.exp LINK : fatal error LNK1101: incorrect MSPDB80.DLL version; recheck installation of this product As I haven't installed anything on this VM and only have ssh access, I've got no idea what/how to check. It's just a copy of a standard VM installation we have as far as I know. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 22:44:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 20:44:08 +0000 Subject: [M3devel] cl on windows In-Reply-To: <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> Message-ID: Hm. Backup. I'm not sure what's going on so I'll be more conservative. Did you install Visual C++ or copy it around? Did you set %PATH% or run the start menu shortcut that Randy suggested? Try installing rather than copying. Try the start menu shortcut, then set PATH=%PATH%;c:\cygwin\bin (or PATH=C:\cygwin\bin;%PATH% if you delete the Cygwin link.exe) Kill any mspdbsrv.exe process. Not repeatedly, but once. Did you start with my VC80 cm3 or my VC90 cm3? - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 22:30:37 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; khaeusler at elegosoft.com > Subject: Re: [M3devel] cl on windows > > Quoting Jay K : > >> Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. >> Cygwin's link.exe is a synonym for ln.exe. > > One step further thanks to your hint. Now dynamic linking fails: > > Creating library sysutils.lib and object sysutils.exp > LINK : fatal error LNK1101: incorrect MSPDB80.DLL version; recheck > installation of this product > > As I haven't installed anything on this VM and only have ssh access, > I've got no idea what/how to check. It's just a copy of a standard > VM installation we have as far as I know. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From dragisha at m3w.org Fri Jul 31 00:20:39 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 00:20:39 +0200 Subject: [M3devel] M3Config In-Reply-To: References: Message-ID: <1248992439.2801.9.camel@faramir.m3w.org> I have code reading data structure information from .M3WEB files.... And that code used M3Config for obvious things... Now when you killed it, how I am supposed (in portable way) to find these files? :) TIA, dd On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > So..I was wondering..what were the original authors thinking? > > And there was that comment about the file containing the data upon > install. > Which seemed wrong to me. > > They were probably thinking of the way 3.6 was packaged and > distributed -- everyone built the system from source, upon building > m3build/m3ship from C and m3 from assembly. > > That isn't a bad model, but we probably want both. > > There are at least three times the paths can be computed/recorded: > 1) when you build libm3 > 2) when you install libm3 > #1 and #2 may or may not be close in time and have the same result. > 3) by parsing cm3.cfg as needed > > #2 is more efficient than #3 and matches the old code, but #3 is how I > left it, probably ok. > > - Jay > -- Dragi?a Duri? From dragisha at m3w.org Fri Jul 31 00:17:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 00:17:47 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: <1248992267.2801.7.camel@faramir.m3w.org> cm3 -? ... > CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, > "make DESTDIR=" behaviour for cm3 > This is one patch I've introduced earlier and it's excellent conduit for RPM packaging scripts I develop. I am using it like this: > export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT > > ./scripts/do-pkg.sh realclean m3core libm3 > > ./scripts/do-pkg.sh buildship m3core libm3 > Please let me know if your script fails on you mentioning mkdir failure. I have workaround for it (as Jay did not accept my report as a bug). I'll put my RPM script in repository RSN. dd On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 03:27:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 01:27:23 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1248992267.2801.7.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: > I have workaround for it (as Jay did not accept my report as a bug). I believe I fixed it. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Fri, 31 Jul 2009 00:17:47 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > cm3 -? > ... >> CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, >> "make DESTDIR=" behaviour for cm3 >> > > This is one patch I've introduced earlier and it's excellent conduit for > RPM packaging scripts I develop. I am using it like this: > > >> export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT >> >> ./scripts/do-pkg.sh realclean m3core libm3 >> >> ./scripts/do-pkg.sh buildship m3core libm3 >> > > Please let me know if your script fails on you mentioning mkdir failure. > I have workaround for it (as Jay did not accept my report as a bug). > > > I'll put my RPM script in repository RSN. > > dd > > On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: >> Hi Jay, >> >> Do you know of any way to tell the build system that the >> final installation directory is located in one place, but >> that the software is to actually be shipped (temporarily) >> to a staging directory. >> >> Specifically, libm3/src/config contains a m3makefile that >> derives the M3Config interface, containing a number of >> paths to the installation root directory. >> >> This is the normal situation for most people, but I am >> installing to a temporary directory, for packaging purposes. >> The packaging software later installs the package into >> the correct location. >> >> Whenever I build the system, M3Config always contains >> the paths to my staging area. >> >> I would like some way of specifying to the build system >> that the final (or real) installation root is one thing, >> but "ship" would actually install into a different one. >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 03:30:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 01:30:04 +0000 Subject: [M3devel] M3Config In-Reply-To: <1248992439.2801.9.camel@faramir.m3w.org> References: <1248992439.2801.9.camel@faramir.m3w.org> Message-ID: It was partly unsupportable and you can trivially replace it with MxConfig. Please try that -- MxConfig. MxConfig.Get() I recall. We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 00:20:39 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config > > I have code reading data structure information from .M3WEB files.... And > that code used M3Config for obvious things... Now when you killed it, > how I am supposed (in portable way) to find these files? :) > > TIA, > dd > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: >> So..I was wondering..what were the original authors thinking? >> >> And there was that comment about the file containing the data upon >> install. >> Which seemed wrong to me. >> >> They were probably thinking of the way 3.6 was packaged and >> distributed -- everyone built the system from source, upon building >> m3build/m3ship from C and m3 from assembly. >> >> That isn't a bad model, but we probably want both. >> >> There are at least three times the paths can be computed/recorded: >> 1) when you build libm3 >> 2) when you install libm3 >> #1 and #2 may or may not be close in time and have the same result. >> 3) by parsing cm3.cfg as needed >> >> #2 is more efficient than #3 and matches the old code, but #3 is how I >> left it, probably ok. >> >> - Jay >> > -- > Dragi?a Duri? > From rcoleburn at scires.com Fri Jul 31 03:54:08 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 21:54:08 -0400 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <4A721600.1E75.00D7.1@scires.com> Olaf: Using the "do-cm3.cmd" script that I checked in, I am currently able to compile and link on both Windows XP and Vista all packages listed in PkgInfo.txt , except for the packages that have been disabled via the m3makefile for NT386. Again, I suspect your problem may be in using cygwin. I infer that you are using cygwin based on the path name below "C:\cygwin\usr\local...". Again, this is further evidence why there needs to be a distinction between a CM3 installation for Windows and one for cygwin running on Windows; and why the supporting scripts may need to be different. Of course, if Jay succeeds in getting the python scripts to be truly "portable" between the various platforms, it may cut down on the maintenance, since we won't need a different script for every platform. For now, I'm holding fast to Windows CMD because I can make it work and I don't have to install anything else to get it to work. Regards, Randy >>> Olaf Wagner 7/30/2009 1:23 PM >>> Thanks for the answer, Randy. I had just remembered that I needed to set a number of variables. Attached is the shell script I came up with. Compilation works now without a problem. I get as far as linking: new source -> compiling WinUserC.c -> archiving m3core.lib link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 9 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** This seems to be a problem in the cm3 configuration files, right? More evidence: elego at wagner ~/work/cm3 $ (cd m3-libs/m3core; cm3 -commands -build -keep) --- building in NT386 --- cd NT386 ignoring ..\src\m3overrides rm .M3SHIP rm .M3OVERRIDES inhale m3core.m3x -> archiving m3core.lib rm m3core.lib rm m3core.lib rm m3core.lib.sa rm m3core.dll rm m3core.def rm m3core.lst rm m3core.dll.manifest rm m3core.pdb rm _m3responsefile0.txt rm _m3responsefile1.txt rm m3core.ilk rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk mklib @_m3responsefile0.txt 2>&1 > m3core.lst rm m3core.lib rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk link @_m3responsefile1.txt 2>&1 > m3core.lst link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 6 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. cd .. elego at wagner ~/work/cm3 $ cat m3-libs/m3core/NT386/_m3responsefile1.txt -nodefaultlib -debug -incremental:no -opt:ref -delayload:wsock32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll delayimp.lib -def:m3core.def -dll -out:m3core.dll -noentry hand.obj dtoa.obj libgcc.obj RTHooks.io RTHooks.mo [...lots of objects removed...] kernel32.lib msvcrt.lib Olaf PS: I don't think that just returning 53 is the correct way to remind users that some environment settings are missing though :-) Quoting Randy Coleburn : > Olaf: > > I don't think you want to be doing this with cygwin. That would mean > you are executing in a cygwin environment, not a true Windows-only > environment. > > For the Visual Studio command line to work, you have to run the script > that sets up the environment variables. From the Windows Start menu, > there should be a menu tree labeled "Visual C++ 9.0 Express > Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". > Choosing this item from the menu will bring up a command prompt with the > environment set up properly. > > Alternately, you can run the following command from an existing command > prompt window: "C:\Program Files\Microsoft Visual Studio > 9.0\VC\vcvarsall.bat x86" > > Note that the above command line assumes you have installed Visual C++ > 2008 Express Edition. The paths may be different for different versions > of the software. > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or > cm3SetupCmdEnv.CMD), they do this all for you. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 06:14:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 00:14:54 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> Message-ID: <4A7236FD.1E75.00D7.1@scires.com> Jay: Thanks for your reply. I really appreciate your patience in dealing with all my questions, especially during this busy time preparing for the release. In response, I offer the following and also ask a few more questions: My use of the term "minimal" is consistent with what has been documented in the working release documentation. Namely, that "min" is the smallest distribution we plan to make available, versus "std" that contains a "standard" distribution, versus "all" that contains everything. Now as to the exact composition of "min" and "std" that is part of my question. I assumed someone (you, Olaf, Tony, ?) has defined what these mean. Further, if you look at PkgInfo.txt, it appears that these definitions are recorded there, but again back to my question as to whether these definitions are accurate, complete, what the "cm3 community" wants/expects, and whether my understanding of how they are used in the context of cm3 is indeed correct. I am well-versed in compilers and operating systems principles and design, so I don't need a lecture on these fundamentals. My line of questioning is concrete with respect to the impending cm3 release. My use of the term "build" is in the context of "cm3 -build", and to be useful, subsequently "cm3 -ship". As a software/systems engineer, I understand what you mean when you say that the code is the documentation when there is no external documentation. However, I would hope you agree that no external documentation is generally a bad thing. Hence my questions. I'm not a python code writer yet, though I'm confident I could be, given some time to learn. Thus, I can't presently rely on reading a python script as documentation. I am confident that if you, Olaf, Tony, or someone can confirm or correct my understanding of what I've posed as the way to install the "min" distribution on Windows and "build" the rest, that I can and will be able to document this process externally for others to review. We can then check scripts to see if they deviate from the documentation and make changes (to either scripts or documentation) as needed to reflect reality. You state that I have not defined the "goal." Let me attempt to make this obvious. I'm not trying to upset the apple cart here or change the way you work to achieve progress/success. My goal simply is to "understand" wrt the impending release so I can document, and so I can "do the right thing" to make this work correctly on my system. We can discuss in the future how things should change for the next release. Thanks for help with my 13-steps. I have some comments and a few more questions below. WRT #1, Yes, I know I may not need all of Visual Studio, but most users will just choose the typical installation. If we have specific minimums that need to be present, we should identify (document) those for users who choose to customize their installation. WRT #2, you have to start somewhere. If we have both "min" and "std" distributions, one can choose which to start with, but your discussion of which parts to trim out of "min" should not be left to the end user. The release team needs to establish what constitutes "min". My "opinion" is that "min" should contain only what is necessary for a working cm3 compiler, given the dependency on the platform-specific linker. Using "min" one should be able to build (cm3 -build -ship) all other packages. Anything added to "min" that isn't necessary to accomplish building the remaining packages would be considered superfluous, in my opinion. Some amount of superfluous on a given platform may be tolerable in order to reach consistency among all supported platforms regarding the composition of "min". Thus, if cm3cg is needed for "min" on some platforms, but not all, it is tolerable (IMO) to make it a standard component of "min" on all platforms. WRT #3, point taken. However, unless we have an easy way to specify and checkout only those parts of the tree relevant to a particular platform, checking out everything ensures you haven't missed something that is going to cause problems later. WRT#4, although doc may not be needed to run cm3, it is needed for folks to reference and understand cm3. This is a long-standing gripe of mine that we don't make the installation of doc part of the typical installation. The naive user new to cm3 normally expects to get some documentation. If the default is no documentation, how does the poor sap know how to get the documentation and install it? Also, cm3ide, does have links to the doc folder. If you click on these links and they are broken, the average user is going to rate cm3 as a poor product and move on to something else. Why create a problem for the new user? Give him the documentation he needs by default and let the expert user remove it if it is unwanted. I know that Critical Mass's 4.1 installation put the doc folder there. When did someone decide it wasn't appropriate for the default installation? WRT#5, examples is needed for cm3ide. Right now, my bet is that most everyone in the cm3 community doesn't know they should copy the examples folder to the root of their cm3 installation. That's because Reactor wasn't open-sourced until recently as cm3ide. Right now the only documentation about this is a README file buried in the repository and even that wouldn't be there if I hadn't put it there. Again, don't create a problem for the new user. The "typical" installation choice should install it by default. Let the expert user choose to remove it as part of a custom install if it is not wanted. WRT#6, agree. That's why I wasn't specific on how to do it, but for the newbie, it would probably be best to list at least one way. WRT#7, agree. I was just stating my interpretation of what you had communicated to me earlier about setting up config properly. WRT#8, ok, but you do get an error message if the folder exists already. WRT#9, ditto #7 WRT#11, now we are finally getting to the meat of my questions. So, if I understand you correctly, you are saying that building the "min" group of packages does not recreate for me exactly what is being published as the "min" distribution. In my view, we have a conflict of terminology here that needs to be cleaned up. So what exactly is "min" as defined in PkgInfo.txt if it doesn't represent the minimal binary install? Furthermore, if I want to use cm3 to build the sources for the compiler itself, it would seem from your comments that "min" won't do it. Which packages need to built, and in what order, to recreate cm3.exe ? Again you ask about the goal here, so let me be more explicit. Given that cm3 continues to evolve and that minimal distributions are created at unpredictable intervals, if one wants to ensure the cm3 compiler is up-to-date with the latest sources, one would want to start with some existing cm3 installation and build and ship the compiler's source package(s) along with any other packages where a dependency exists. In these instructions, I started with obtaining the latest "min" distribution, then grabbed the current source tree, so I want to proceed from this point to build a current cm3 compiler and any other requisite components to again create a "minimal" installation on my platform. From there, one can build some/all of the remaining packages. WRT#12, the repeat is due to my prior understanding. Perhaps this is incorrect, or perhaps the recent changes have made this unnecessary. But, it seems my understanding of how to rebuild cm3.exe is flawed given your response to #11. Are you saying I should use "front" to build cm3.exe? Am I the only one to whom all this is unclear? Again, we need to document for understanding. WRT#13, not sure what you mean by "sort of". What are the caveats? Regarding your comment at the end about scripts, I will respectfully choose to disagree with you and hope that we work together to improve documentation. After all, if we all get run over by a truck, what we know in our brains isn't available to others unless we've documented it somewhere. Thanks for your patience in putting up with all my questions! Thanks also for all you are doing for cm3! Regards, Randy Coleburn >>> Jay K 7/30/2009 4:11 PM >>> Randy, the short answer is: Find a goal state in a graph, which you haven't clearly done, walk that graph from the bottom up, and if there are circularities (there are, you need to have cm3 first, before you can build cm3), you need to download prebuilt files from somewhere (cm3 and mklib). Everything else is filling in the details of the goal state, discovering the circularities, and that we have the graph recorded in a redundant fashion in pkginfo.txt. The real data is the m3makefiles. longer answer: Randy, what is a "minimal" distribution? You have't defined the goal. What is "build"? You haven't defined the goal. I could just say: "Whatever you need, to build it, just download it from here." I'll define it as some arbitrary very minimal compiler and runtime set, specifically m3core and libm3. But you can have working Modula-3 programs certainly without libm3. And some Modula-3 programs will have a GUI so will want more libraries. What is "minimal"? And depending on future changes, the steps might change. Or maybe just pkginfo.txt will change. If there is no documentation and there is code, the code is the documentation. A lot of the code is declarative -- you look at the import statements in m3makefile. For given package foo, say "cm3", you walk the list of imports transitively. I'm not sure cm3 actually uses libm3 for example, and maybe it won't in the future. This is a very real point. pkginfo.txt duplicates dependency information by nature of being "in the correct order", but that information is already contained in the m3makefiles. Your questions have made me realize the redundancy we have and that we should fix it. Or, really, older cm3 did not use sysutils, but now it does. Things change. And you haven't really defined the goal. Instead of "walk pkginfo.txt in order", it should be "pick a package you want, say cm3, and build its dependency tree from the bottom up, using the m3makefiles to discover that tree, plus the PKGS file to locate packages". I'm going to make up a goal that might resemble yours and correct your instructions. > 1. Install Visual C++ 2008 Express Edition. ok. Though you don't need all of it by far. You don't need the entire IDE. > > 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. No. You don't need all of it. You only need two files -- cm3.exe and mklib.exe. Other platforms need cm3cg and don't need mklib. Except you never really need cm3cg, it falls out of the instructions -- cm3 can build it. It depends on how much you want to build vs. download. And optionally the config files. You can get them from either the source tree or download them. See, two legitimate places for things -- download from one place or another. > > > 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. No. You don't need all of it. You need, roughly, only m3-libs\m3core, m3-libs\libm3, m3-libs\sysutils, some of m3-sys. m3-sys/m3cc is needed for most platforms, but not the gcc-apple directory, that's only for iphone. > > 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" Not needed. > > 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" Not needed. > > 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. Many ways to do that. > > > 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. Multiple ways to do this but ok. > > > 8. mkdir "C:\cm3\bin\config" if it is missing ok. You can just mkdir unconditionally. > > > 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" You don't need all of it, but ok, that is what I do. > > > 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: > > INSTALL_ROOT = path() & "/.." > > include(path() & "/config/" & HOST) ok > > > 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) No. Well, it depends on the goal. Really. You already have a cm3. "min" gives you m3core and libm3. Combine that with the cm3 you already have and great, you have a slightly larger more useful set of libraries. > > > 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. NOt really. The repitition isn't doing what you say. Look at the group called "front". Which isn't completely accurate since it includes m3cc. Perhaps there should be a group compiler. But really, again, this is cm3 plus its transitive dependencies. I think maybe we need to partly ditch "groups". In paritcular, "groups" should contain useful end results and not their dependencies. m3middle doesn't belong in any group, it is just implied by cm3. Seriously. But the scripts don't currently read m3makefiles. Redoing things in cm3 would be better? > > > 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". Ok. Sort of. > > I know you've probably got scripts for all of this Yep. > Scripts are an expression of the requirements Sometimes it is the other way around. - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 31 06:28:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 00:28:55 -0400 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: Randy, I think this is a very useful exposition of the requirements for release distributions. I trust that your concerns can be addressed by Jay and Olaf. I must admit that, at this point, I have lost track of where things stand in the release installation process and hope soon to bring myself up to date. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 31 Jul 2009, at 00:14, Randy Coleburn wrote: > Jay: > > Thanks for your reply. I really appreciate your patience in dealing > with all my questions, especially during this busy time preparing > for the release. > > In response, I offer the following and also ask a few more questions: > > My use of the term "minimal" is consistent with what has been > documented in the working release documentation. Namely, that "min" > is the smallest distribution we plan to make available, versus "std" > that contains a "standard" distribution, versus "all" that contains > everything. > > Now as to the exact composition of "min" and "std" that is part of > my question. I assumed someone (you, Olaf, Tony, ?) has defined > what these mean. Further, if you look at PkgInfo.txt, it appears > that these definitions are recorded there, but again back to my > question as to whether these definitions are accurate, complete, > what the "cm3 community" wants/expects, and whether my understanding > of how they are used in the context of cm3 is indeed correct. > > I am well-versed in compilers and operating systems principles and > design, so I don't need a lecture on these fundamentals. My line of > questioning is concrete with respect to the impending cm3 release. > > My use of the term "build" is in the context of "cm3 -build", and to > be useful, subsequently "cm3 -ship". > > As a software/systems engineer, I understand what you mean when you > say that the code is the documentation when there is no external > documentation. However, I would hope you agree that no external > documentation is generally a bad thing. Hence my questions. I'm > not a python code writer yet, though I'm confident I could be, given > some time to learn. Thus, I can't presently rely on reading a > python script as documentation. I am confident that if you, Olaf, > Tony, or someone can confirm or correct my understanding of what > I've posed as the way to install the "min" distribution on Windows > and "build" the rest, that I can and will be able to document this > process externally for others to review. We can then check scripts > to see if they deviate from the documentation and make changes (to > either scripts or documentation) as needed to reflect reality. > > You state that I have not defined the "goal." Let me attempt to > make this obvious. I'm not trying to upset the apple cart here or > change the way you work to achieve progress/success. My goal simply > is to "understand" wrt the impending release so I can document, and > so I can "do the right thing" to make this work correctly on my > system. We can discuss in the future how things should change for > the next release. > > Thanks for help with my 13-steps. I have some comments and a few > more questions below. > > WRT #1, Yes, I know I may not need all of Visual Studio, but most > users will just choose the typical installation. If we have > specific minimums that need to be present, we should identify > (document) those for users who choose to customize their installation. > > WRT #2, you have to start somewhere. If we have both "min" and > "std" distributions, one can choose which to start with, but your > discussion of which parts to trim out of "min" should not be left to > the end user. The release team needs to establish what constitutes > "min". My "opinion" is that "min" should contain only what is > necessary for a working cm3 compiler, given the dependency on the > platform-specific linker. Using "min" one should be able to build > (cm3 -build -ship) all other packages. Anything added to "min" that > isn't necessary to accomplish building the remaining packages would > be considered superfluous, in my opinion. Some amount of > superfluous on a given platform may be tolerable in order to reach > consistency among all supported platforms regarding the composition > of "min". Thus, if cm3cg is needed for "min" on some platforms, but > not all, it is tolerable (IMO) to make it a standard component of > "min" on all platforms. > > WRT #3, point taken. However, unless we have an easy way to specify > and checkout only those parts of the tree relevant to a particular > platform, checking out everything ensures you haven't missed > something that is going to cause problems later. > > WRT#4, although doc may not be needed to run cm3, it is needed for > folks to reference and understand cm3. This is a long-standing > gripe of mine that we don't make the installation of doc part of the > typical installation. The naive user new to cm3 normally expects to > get some documentation. If the default is no documentation, how > does the poor sap know how to get the documentation and install it? > Also, cm3ide, does have links to the doc folder. If you click on > these links and they are broken, the average user is going to rate > cm3 as a poor product and move on to something else. Why create a > problem for the new user? Give him the documentation he needs by > default and let the expert user remove it if it is unwanted. I know > that Critical Mass's 4.1 installation put the doc folder there. > When did someone decide it wasn't appropriate for the default > installation? > > WRT#5, examples is needed for cm3ide. Right now, my bet is that > most everyone in the cm3 community doesn't know they should copy the > examples folder to the root of their cm3 installation. That's > because Reactor wasn't open-sourced until recently as cm3ide. Right > now the only documentation about this is a README file buried in the > repository and even that wouldn't be there if I hadn't put it > there. Again, don't create a problem for the new user. The > "typical" installation choice should install it by default. Let the > expert user choose to remove it as part of a custom install if it is > not wanted. > > WRT#6, agree. That's why I wasn't specific on how to do it, but for > the newbie, it would probably be best to list at least one way. > > WRT#7, agree. I was just stating my interpretation of what you had > communicated to me earlier about setting up config properly. > > WRT#8, ok, but you do get an error message if the folder exists > already. > > WRT#9, ditto #7 > > WRT#11, now we are finally getting to the meat of my questions. So, > if I understand you correctly, you are saying that building the > "min" group of packages does not recreate for me exactly what is > being published as the "min" distribution. In my view, we have a > conflict of terminology here that needs to be cleaned up. So what > exactly is "min" as defined in PkgInfo.txt if it doesn't represent > the minimal binary install? Furthermore, if I want to use cm3 to > build the sources for the compiler itself, it would seem from your > comments that "min" won't do it. Which packages need to built, and > in what order, to recreate cm3.exe ? > > Again you ask about the goal here, so let me be more explicit. > Given that cm3 continues to evolve and that minimal distributions > are created at unpredictable intervals, if one wants to ensure the > cm3 compiler is up-to-date with the latest sources, one would want > to start with some existing cm3 installation and build and ship the > compiler's source package(s) along with any other packages where a > dependency exists. In these instructions, I started with obtaining > the latest "min" distribution, then grabbed the current source tree, > so I want to proceed from this point to build a current cm3 compiler > and any other requisite components to again create a "minimal" > installation on my platform. From there, one can build some/all of > the remaining packages. > > WRT#12, the repeat is due to my prior understanding. Perhaps this > is incorrect, or perhaps the recent changes have made this > unnecessary. But, it seems my understanding of how to rebuild > cm3.exe is flawed given your response to #11. Are you saying I > should use "front" to build cm3.exe? Am I the only one to whom all > this is unclear? Again, we need to document for understanding. > > WRT#13, not sure what you mean by "sort of". What are the caveats? > > Regarding your comment at the end about scripts, I will respectfully > choose to disagree with you and hope that we work together to > improve documentation. After all, if we all get run over by a > truck, what we know in our brains isn't available to others unless > we've documented it somewhere. > > Thanks for your patience in putting up with all my questions! > Thanks also for all you are doing for cm3! > > Regards, > Randy Coleburn > >>>> Jay K 7/30/2009 4:11 PM >>> > > > Randy, the short answer is: > > Find a goal state in a graph, which you haven't clearly done, walk > that graph from the bottom up, and if there are circularities (there > are, you need to have cm3 first, before you can build cm3), you need > to download prebuilt files from somewhere (cm3 and mklib). > > > Everything else is filling in the details of the goal state, > discovering the circularities, and that we have the graph recorded > in a redundant fashion in pkginfo.txt. The real data is the > m3makefiles. > > > longer answer: > > > > Randy, what is a "minimal" distribution? You have't defined the goal. > What is "build"? You haven't defined the goal. > I could just say: "Whatever you need, to build it, just download it > from here." > > > I'll define it as some arbitrary very minimal compiler and runtime > set, specifically m3core and libm3. > But you can have working Modula-3 programs certainly without libm3. > And some Modula-3 programs will have a GUI so will want more > libraries. > What is "minimal"? > And depending on future changes, the steps might change. > Or maybe just pkginfo.txt will change. > If there is no documentation and there is code, the code is the > documentation. > > > A lot of the code is declarative -- you look at the import > statements in m3makefile. > For given package foo, say "cm3", you walk the list of imports > transitively -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 07:05:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 01:05:45 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content Message-ID: <4A7242E8.1E75.00D7.1@scires.com> Jay et al: On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. In particular, these are: BUILD_DIR PKG_USE DOC_INSTALL INSTALL_ROOT INITIAL_CM3_IDE_BROWSER INITIAL_CM3_IDE_EDITOR If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jul 31 08:10:35 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 08:10:35 +0200 Subject: [M3devel] M3Config In-Reply-To: References: <1248992439.2801.9.camel@faramir.m3w.org> Message-ID: <1249020635.2801.476.camel@faramir.m3w.org> Of course I do not insist. I need function, form is what someone with wider insight can decide much better. It's a bit... unusual... to depend on m3quake, but then... it's probably very unusual to read .M3WEB's too. I'll try it, thanks. dd On Fri, 2009-07-31 at 01:30 +0000, Jay K wrote: > It was partly unsupportable and you can trivially replace it with MxConfig. > Please try that -- MxConfig. MxConfig.Get() I recall. > > > We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). > > > - Jay > > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 31 Jul 2009 00:20:39 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] M3Config > > > > I have code reading data structure information from .M3WEB files.... And > > that code used M3Config for obvious things... Now when you killed it, > > how I am supposed (in portable way) to find these files? :) > > > > TIA, > > dd > > > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > >> So..I was wondering..what were the original authors thinking? > >> > >> And there was that comment about the file containing the data upon > >> install. > >> Which seemed wrong to me. > >> > >> They were probably thinking of the way 3.6 was packaged and > >> distributed -- everyone built the system from source, upon building > >> m3build/m3ship from C and m3 from assembly. > >> > >> That isn't a bad model, but we probably want both. > >> > >> There are at least three times the paths can be computed/recorded: > >> 1) when you build libm3 > >> 2) when you install libm3 > >> #1 and #2 may or may not be close in time and have the same result. > >> 3) by parsing cm3.cfg as needed > >> > >> #2 is more efficient than #3 and matches the old code, but #3 is how I > >> left it, probably ok. > >> > >> - Jay > >> > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 08:45:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 06:45:51 +0000 Subject: [M3devel] cl on windows In-Reply-To: <4A721600.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <4A721600.1E75.00D7.1@scires.com> Message-ID: > Again, I suspect your problem may be in using cygwin. I infer that you are using cygwin based on the path name below "C:\cygwin\usr\local...". Again, really, no. All both Cygwin and the vcvars32.bat are adding elements to %PATH%, and %LIB%, and %INCLUDE%, and adding files within the directories within %PATH%. The only way in which they collide is when they have file names in common, such as link.exe, or, indeed, python.exe. (or multiple copies of cygwin1.dll, because it uses a shared section, which is a security bug, which they seem to ignore that and just claim that Windows is insecure so they have no problem making things worse...multiple users who don't trust themselves have read/write access to some of each other's memory in this setup..) > if Jay succeeds in getting the python scripts to be truly "portable" > between the various platforms Again, I already have. I wrote them on a Mac to start, and since them have run on then OpenBSD, NetBSD, FreeBSD, Linux (Gentoo, Debian, maybe Red Hat), Solaris, NT, HP-UX, Cygwin, Interix, Darwin (not the full Mac OSX, which is where they ran first), and maybe more that is all I can remember. What are the errors you get? I have asked a few times. - Jay From jay.krell at cornell.edu Fri Jul 31 08:48:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 06:48:59 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content In-Reply-To: <4A7242E8.1E75.00D7.1@scires.com> References: <4A7242E8.1E75.00D7.1@scires.com> Message-ID: BUILD_DIR is defined. cm3 requires it too. It just isn't necessarily defined in the toplevel file, but in a file that gets included. > PKG_USE I believe that is also defined but I'll check. > DOC_INSTALL I doubt that is defined because I never saw it used. I can add it back. > INSTALL_ROOT That is certainly defined, and very important. > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR These are probably also not defined because I never saw them used. I can add them back..but they are actually very user specific. I can add defaults like: BROWSER=iexplore.exe EDITOR=notepad.exe BROWSER=firefox-bin EDITOR=/usr/bin/vi I'll do a little reserach and try to find defaults that work. - Jay ________________________________ > Date: Fri, 31 Jul 2009 01:05:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content > > > > > > > > Jay et al: > > > > On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. > > > > cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". > > > > I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. > > > > At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. > > > > In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. > > > > In particular, these are: > > BUILD_DIR > > PKG_USE > > DOC_INSTALL > > INSTALL_ROOT > > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR > > > > If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. > > > > I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. > > > > It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. > > > > Regards, > > Randy Coleburn From jay.krell at cornell.edu Fri Jul 31 09:06:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:06:15 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1248992267.2801.7.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: Please consider that you don't really need this CM3_INSTALL_PREFIX feature. I understand what it does. And the implementation is pretty small and ok. I don't mind leaving it in. And I think I fixed the problem with it. I hope it is clear that it isn't really needed. I will explain why. It isn't needed because the default ship location is adequate. The default ship location is the location of cm3, or one level up from there, or uh, whatever the config file says, but that is what it usually is. Now, granted, the location of cm3 "right now" might not be what you want. However, copying cm3 to where you want shipping to go is cheap, if in fact you are after building the whole system. If you are after just building a few packages, then, indeed, what I am saying makes less/no sense. gcc for example, is a bit heavyweight to copy around. It is many files. However cm3 is very small. If you want to ship somewhere else, you can do this: mkdir -p /tmp/foo/bin/config cd /tmp/foo/bin cp /usr/local/bin/cm3 . cp /usr/local/bin/cm3.cfg . cp /usr/local/bin/config/* config export PATH=/tmp/foo/bin:$PATH That's it. Then go about building the distribution, I'm not sure of the order here, but I'm sick of arguing about scripts and package groups and pkginfo.txt, the whole lot is unnecessary. cd $CVSROOT/m3-sys/m3cc cm3 -build cm3 -ship cd $CVSROOT/m3-libs/m3core cm3 -build cm3 -ship cd $CVSROOT/m3-libs/libm3 cm3 -build cm3 -ship cd $CVSROOT/m3-libs/sysutils cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3quake cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3middle cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3front cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3linker cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3back cm3 -build cm3 -ship cd $CVSROOT/m3-sys/cm3 cm3 -build cm3 -ship oops this line doesn't do anything useful # rem next line makes up for previous line not "working" cp build_dir/cm3 /tmp/foo/bin and continue on your way building/shipping whatever Again, if you just want to package up some gui apps for example, not the whole system from scratch, then CM3_INSTALL_PREFIX becomes more useful. I do wonder if the usage should have been cm3 -ship DESTDIR=/tmp/foo to follow widespread existing practice, but ok either way. Apple also uses a different name like DSTROOT for their linker/assembler and such. This technique is how I build distributions and I believe how Olaf does too, since I based my code on his. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Fri, 31 Jul 2009 00:17:47 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > cm3 -? > ... >> CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, >> "make DESTDIR=" behaviour for cm3 >> > > This is one patch I've introduced earlier and it's excellent conduit for > RPM packaging scripts I develop. I am using it like this: > > >> export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT >> >> ./scripts/do-pkg.sh realclean m3core libm3 >> >> ./scripts/do-pkg.sh buildship m3core libm3 >> > > Please let me know if your script fails on you mentioning mkdir failure. > I have workaround for it (as Jay did not accept my report as a bug). > > > I'll put my RPM script in repository RSN. > > dd > > On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: >> Hi Jay, >> >> Do you know of any way to tell the build system that the >> final installation directory is located in one place, but >> that the software is to actually be shipped (temporarily) >> to a staging directory. >> >> Specifically, libm3/src/config contains a m3makefile that >> derives the M3Config interface, containing a number of >> paths to the installation root directory. >> >> This is the normal situation for most people, but I am >> installing to a temporary directory, for packaging purposes. >> The packaging software later installs the package into >> the correct location. >> >> Whenever I build the system, M3Config always contains >> the paths to my staging area. >> >> I would like some way of specifying to the build system >> that the final (or real) installation root is one thing, >> but "ship" would actually install into a different one. >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 09:39:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:39:01 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: I'm sorry but I'm feeling very impatient... > Namely, that "min" is the smallest distribution we plan to make available Ok, that is clearer. That is not scientific but a matter of a decision. We could decide that min==std, not a bad decision really, since it gives users fewer confusing choices, and provides one package per platform, with no overlap. On the downside, it isn't small and some people might say we look fat. > My "opinion" is that "min" should contain only what is > necessary for a working cm3 compiler Now you have made a policy decision. An acceptable one. But not necessarily how it should and not necessarily consistent with some other things. > Anything added to "min" that isn't necessary to accomplish > building the remaining packages would be considered superfluous, > in my opinion. > Some amount of superfluous on a given platform may be > tolerable in order to reach consistency among all supported > platforms regarding the composition of "min". Thus, > if cm3cg is needed for "min" on some platforms, but not all, > it is tolerable (IMO) to make it a standard component of "min" > on all platforms. cm3cg doesn't really make sense on NT386 though. I've probably thrown it in somewhat by accident. If it is there, it'll depend on Cygwin, and NT386 will just ignore it completely, except for wasted diskspace, network traffic. > WRT#4, although doc may not be needed to run cm3, it is needed > for folks to reference and understand cm3. Now you are expanding the definition. The documentation is all online too. I'm certainly fine with including the documentation. Just be clear that "min"'s definition is expanding. (I'm fine with not distributing min at all, as I said, min==std?) > The naive user new to cm3 normally expects to get some documentation. I don't expect naive users to build cm3 themselves. This is in fact a reason not to provide min at all, but std. That way, the naive person who thinks he is expert won't make a mistake. Really. On the other hand, there are the masochists among us who use the Debian "netinst" and chose no additional packages during setup. :) If one has the time/patience, it can also be educational to create arbitrary difficult situations and work your way out of them. Really. (Why does anyone use Linux after all?) > If the default is no documentation, how does the poor sap know > how to get the documentation and install it? Poor saps should use "std", not "min". Right? What is "min"? The "minimum" distribution that is useful for "everyone" or the minimal distribution to build cm3? I should correct myself by the way. cm3cg is not needed in "min". It is "easily" just not quickly built from just cm3 and the m3-sys/m3cc part of the tree, and really cm3 is hardly needed for that (but cm3 is definitely needed for building everything else, so needed overall). > [Jay] docs/examples I think it was > The "typical" installation choice should install it by default. "typical" or "min"? > WRT#11, now we are finally getting to the meat of my questions. So, > if I understand you correctly, you are saying that building the "min" > group of packages does not recreate for me exactly what You must start with a prebuilt compiler (cm3). Whether you rebuild the compiler or not is somewhat a matter of taste. Indeed it is more tasteful to build it. In which case indeed, you need to build "front", but "front" need not be in the distribution. "front" is in fact basically just cm3, and I think cm3cg. Again again again, the "package groups" are just a redundant encoding of the dependency tree that is encoded in the m3makefiles. We could the entire scripts directory and pretty much everything would work about the same. It would just be a little tedious. More and more I think we should actually delete a lot of this. We should keep the PKGS file, or make cm3 able to figure it out, and the "scripts" should just accept an end goal -- "cm3", and it should read the m3makefiles and build the dependency graph from the buttom up to the goal. There could be special goal called "all", AND we could have the broken m3makefiles all filter themselves out. Perhaps a special group called "test", whose membership is implied by path? But now, you see, the more of these features I add, the more I'm back to reinventing these minor little scripts and package groups that we have. But do you see, that these aren't sort of all that significant? What you need to build is whatever m3makefiles lists in imports, and follow the transitive closure. And cm3cg is sort of different -- because it isn't a linked/library dependency, but rather because the config files tries to run a program (cm3cg) and that program needs to therefore exist somewhere. That is, the linked/library dependencies are encoded in a nice declarative way in the m3makefiles but the dependency on cm3cg is encoded in an imperative way. My interpretion of "min" has been roughly a minimal distribution that one can start with in order to build cm3, EVEN IF old cm3 cannot build m3core and libm3 from current source. The part I don't understand is that last point -- is it considered a recurring problem? Where is the line? What about sysutils? Is sysutils expected to be forever bound to be buildable by arbitrarily old compilers? Do we make a release shortly any such incompatibilities occur? Do we in fact not cater to such incompatibilities, and "min" therefore does NOT include m3core and libm3? Historically there was actually a more recurring problem here, around the list of targets. That is gone now. However there are still occasional problems like LONGINT. It seems to me this is somewhat of a problem of predicting the future, which is impossible. But also taking out very cheap insurance against the only fairly small number of bad futures. That is, throwing in m3core and libm3 is cheap, and it allows for future versions to not be compilable with old cm3, and that not being a big deal. This is all a bit gray and heuristic however. If today you start with a 5.4 or such cm3, indeed, you cannot build m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3. If you start with yesterday's cm3 however, you can build today's entire system, without also having yesterday's m3core/libm3 (nor cm3cg). See? It depends. And mitigating the worst case is perhaps worthwhile and cheap. And it depends because the system is necessarily circular. ("necessary" because the compiler is written in Modula-3) Breaking circular dependencies requires cheating. Changes in circular graphs can require cheating differently. If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay From dragisha at m3w.org Fri Jul 31 09:47:37 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 09:47:37 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: <1249026457.2801.578.camel@faramir.m3w.org> On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: > mkdir -p /tmp/foo/bin/config > cd /tmp/foo/bin > cp /usr/local/bin/cm3 . > cp /usr/local/bin/cm3.cfg . > cp /usr/local/bin/config/* config > export PATH=/tmp/foo/bin:$PATH Please tell me /usr/local/bin/config/* is mistake here... -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 09:54:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:54:19 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1249026457.2801.578.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> Message-ID: sorry /usr/local/cm3/bin -- or wherever cm3 is installed. I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. Just as /tmp/foo can be replaced by anything. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 09:47:37 +0200 > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: >> mkdir -p /tmp/foo/bin/config >> cd /tmp/foo/bin >> cp /usr/local/bin/cm3 . >> cp /usr/local/bin/cm3.cfg . >> cp /usr/local/bin/config/* config >> export PATH=/tmp/foo/bin:$PATH > > Please tell me /usr/local/bin/config/* is mistake here... > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 09:59:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:59:07 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: [truncated right about here..] If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changes. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay From jay.krell at cornell.edu Fri Jul 31 10:02:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 08:02:33 +0000 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: [wow severely truncated that time...trying again] [truncated right about here..] If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Fri, 31 Jul 2009 07:59:07 +0000 > Subject: Re: [M3devel] package groups question > > > [truncated right about here..] > > > If we do this, it is probably a good idea to also include sysutils in min From dragisha at m3w.org Fri Jul 31 10:00:11 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 10:00:11 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> Message-ID: <1249027211.2801.593.camel@faramir.m3w.org> My question was about location and names of secondary config files. Are these changed again? What would ne shipping procedure for compiler installation? Something new there? /cm3 is excellent idea, but on organized system (and if you package for general public) some standard location is preferred. I will change my locatio to /opt/cm3 now. dd On Fri, 2009-07-31 at 07:54 +0000, Jay K wrote: > sorry /usr/local/cm3/bin -- or wherever cm3 is installed. > I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. > > Just as /tmp/foo can be replaced by anything. > > - Jay > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 31 Jul 2009 09:47:37 +0200 > > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > > > On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: > >> mkdir -p /tmp/foo/bin/config > >> cd /tmp/foo/bin > >> cp /usr/local/bin/cm3 . > >> cp /usr/local/bin/cm3.cfg . > >> cp /usr/local/bin/config/* config > >> export PATH=/tmp/foo/bin:$PATH > > > > Please tell me /usr/local/bin/config/* is mistake here... > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 10:20:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 08:20:49 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1249027211.2801.593.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> <1249027211.2801.593.camel@faramir.m3w.org> Message-ID: The current layout is indeed: installroot/bin/cm3 installroot/bin/cm3.cfg installroot/bin/cm3cg installroot/bin/config/* There are imho too many files in config to put them in bin. cm3.cfg is just a two line stub: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) If you really want the files in, e.g. installroot/etc.: INSTALL_ROOT = path() & "/.." include(path() & "/../etc/" & HOST) or another example you could use is: cd $CVSROOT/m3-sys/cminstall/src/config-no-install cp *.common installroot/cm3/bin cp target installroot/cm3/bin/cm3.cfg or what I use: cd $CVSROOT/m3-sys/cminstall/src/config-no-install cp cm3.cfg installroot/cm3/bin That cm3.cfg delegates out to CM3_ROOT/m3-sys/cminstall/src/config-no-install so that when I am editing in CM3_ROOT/m3-sys/cminstall/src/config-no-install, I don't have to keep copying the file around and never accidentally edit the copy and then wipe it out by recopying it. It is an excellent model imho, but also not for everyone (ie. if you don't have the CVS tree!). It also provides for changing the TARGET somewhat on the fly on "multiarch" systems like NT386+Cygwin, SOLsun + SOLgnu, but I'm no longer liking that model and have started having /cm3, /cm3.cygwin, /cm3.interix on such systems instead. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 10:00:11 +0200 > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > My question was about location and names of secondary config files. Are > these changed again? What would ne shipping procedure for compiler > installation? Something new there? > > /cm3 is excellent idea, but on organized system (and if you package for > general public) some standard location is preferred. I will change my > locatio to /opt/cm3 now. > > dd > > On Fri, 2009-07-31 at 07:54 +0000, Jay K wrote: >> sorry /usr/local/cm3/bin -- or wherever cm3 is installed. >> I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. >> >> Just as /tmp/foo can be replaced by anything. >> >> - Jay >> >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> Date: Fri, 31 Jul 2009 09:47:37 +0200 >>> CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com >>> Subject: Re: [M3devel] M3Config contains paths to installation directory. >>> >>> On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: >>>> mkdir -p /tmp/foo/bin/config >>>> cd /tmp/foo/bin >>>> cp /usr/local/bin/cm3 . >>>> cp /usr/local/bin/cm3.cfg . >>>> cp /usr/local/bin/config/* config >>>> export PATH=/tmp/foo/bin:$PATH >>> >>> Please tell me /usr/local/bin/config/* is mistake here... >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From wagner at elegosoft.com Fri Jul 31 12:10:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 12:10:14 +0200 Subject: [M3devel] cl on windows In-Reply-To: <4A721600.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <4A721600.1E75.00D7.1@scires.com> Message-ID: <20090731121014.dhdyyt3af4s0gcoo@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > Using the "do-cm3.cmd" script that I checked in, I am currently able to > compile and link on both Windows XP and Vista all packages listed in > PkgInfo.txt , except for the packages that have been disabled via the > m3makefile for NT386. > > Again, I suspect your problem may be in using cygwin. I infer that you > are using cygwin based on the path name below "C:\cygwin\usr\local...". I don't think that the problems I encounter are related to cygwin. Think of it as just another shell to execute the production scripts. It's probably simply a broken Visual Studio installation. Tools like compiler and linker should work the same being called from bash or python or cmd.exe. > Again, this is further evidence why there needs to be a distinction > between a CM3 installation for Windows and one for cygwin running on > Windows; and why the supporting scripts may need to be different. Of > course, if Jay succeeds in getting the python scripts to be truly > "portable" between the various platforms, it may cut down on the > maintenance, since we won't need a different script for every platform. There should be a distinction concerning the target platforms (like NT386/NT386GNU as it used to be, but we'll rather use more adequate names). However, this is separate from the production and regression scripts we use. They may be written in shell or python or quake or whatever. I've always used the shell framework, so that's what I use to setup Hudson regression currently. > For now, I'm holding fast to Windows CMD because I can make it work and > I don't have to install anything else to get it to work. That's completely OK and a worthwhile task in itself. Unless you rewrite all the regression scripts in cmd, I cannot really use that though. Olaf > Regards, > Randy > >>>> Olaf Wagner 7/30/2009 1:23 PM >>> > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up > with. > > Compilation works now without a problem. I get as far as linking: > > new source -> compiling WinUserC.c > -> archiving m3core.lib > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 9 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > This seems to be a problem in the cm3 configuration files, right? > > More evidence: > > elego at wagner ~/work/cm3 > $ (cd m3-libs/m3core; cm3 -commands -build -keep) > --- building in NT386 --- > > cd NT386 > ignoring ..\src\m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale m3core.m3x > > -> archiving m3core.lib > rm m3core.lib > rm m3core.lib > rm m3core.lib.sa > rm m3core.dll > rm m3core.def > rm m3core.lst > rm m3core.dll.manifest > rm m3core.pdb > rm _m3responsefile0.txt > rm _m3responsefile1.txt > rm m3core.ilk > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > mklib @_m3responsefile0.txt 2>&1 > m3core.lst > rm m3core.lib > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > link @_m3responsefile1.txt 2>&1 > m3core.lst > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 6 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > cd .. > > elego at wagner ~/work/cm3 > $ cat m3-libs/m3core/NT386/_m3responsefile1.txt > -nodefaultlib > -debug > -incremental:no > -opt:ref > -delayload:wsock32.dll > -delayload:advapi32.dll > -delayload:gdi32.dll > -delayload:netapi32.dll > -delayload:user32.dll > -delayload:comctl32.dll > delayimp.lib > -def:m3core.def > -dll > -out:m3core.dll > -noentry > hand.obj > dtoa.obj > libgcc.obj > RTHooks.io > RTHooks.mo > [...lots of objects removed...] > kernel32.lib > msvcrt.lib > > > Olaf > > PS: I don't think that just returning 53 is the correct way to remind > users that some environment settings are missing though :-) > > Quoting Randy Coleburn : > >> Olaf: >> >> I don't think you want to be doing this with cygwin. That would > mean >> you are executing in a cygwin environment, not a true Windows-only >> environment. >> >> For the Visual Studio command line to work, you have to run the > script >> that sets up the environment variables. From the Windows Start > menu, >> there should be a menu tree labeled "Visual C++ 9.0 Express >> Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". >> Choosing this item from the menu will bring up a command prompt with > the >> environment set up properly. >> >> Alternately, you can run the following command from an existing > command >> prompt window: "C:\Program Files\Microsoft Visual Studio >> 9.0\VC\vcvarsall.bat x86" >> >> Note that the above command line assumes you have installed Visual > C++ >> 2008 Express Edition. The paths may be different for different > versions >> of the software. >> >> Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or >> cm3SetupCmdEnv.CMD), they do this all for you. >> >> Regards, >> Randy Coleburn > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Jul 31 14:31:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 08:31:15 -0400 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> Message-ID: <20090731123115.GA17620@topoi.pooq.com> On Thu, Jul 30, 2009 at 10:16:42PM +0200, Olaf Wagner wrote: > Quoting Peter Eiserloh : > > >Hi Olaf, > > > >www.eiserloh.org is my personal machine, on which I do most of my > >personal stuff. I have been putting things on its web > >server so other people can get to those public items I > >have made. > > > >I will probably have to get an account on birch or something. > > > >Speaking of debian packages, I am building a virtual machine > >for ARM_LINUX using qemu. Currently installing Debian Lenny > >in it. Inside which I will build set of CM3 debian packages > >for ARM. I wonder if that will make it easy to install CM3 programs on Nokia's internet tablets. -- hendrik From jay.krell at cornell.edu Fri Jul 31 14:36:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 12:36:26 +0000 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <20090731123115.GA17620@topoi.pooq.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> <20090731123115.GA17620@topoi.pooq.com> Message-ID: We should be a little careful with ARM_LINUX imho. And MIPS_LINUX. Those target name might be ok, and they'd refer to Linux 2.6+ with glibc. Many ARM and MIPS Linux systems aren't that. ARM has old ABI and new ABI, at the kernel level. It it also common to replace glibc with uclibc. I don't know if they are binary compatible or not. My Linux/arm machine/device is old ABI and uclibc. It seems that if you are building your own kernel, it is trivial to use old ABI. It isn't like it is incompatible with new hardware, I think. I think whoever put together the Western Digital MyBook World Edition just took the default. MIPS..well, I was surprised. I installed "Tomato" on my router. It is /very/ low end, but it does have a builtin SMB client, therefore it has infinite diskspace. It uses Linux 2.4, and I think/assume uclibc. MIPS also has big and little endian and I don't know if either is more common or if it is an even split. - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 08:31:15 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors > > On Thu, Jul 30, 2009 at 10:16:42PM +0200, Olaf Wagner wrote: >> Quoting Peter Eiserloh : >> >>>Hi Olaf, >>> >>>www.eiserloh.org is my personal machine, on which I do most of my >>>personal stuff. I have been putting things on its web >>>server so other people can get to those public items I >>>have made. >>> >>>I will probably have to get an account on birch or something. >>> >>>Speaking of debian packages, I am building a virtual machine >>>for ARM_LINUX using qemu. Currently installing Debian Lenny >>>in it. Inside which I will build set of CM3 debian packages >>>for ARM. > > I wonder if that will make it easy to install CM3 programs on Nokia's > internet tablets. > > -- hendrik From dragisha at m3w.org Fri Jul 31 14:43:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 14:43:41 +0200 Subject: [M3devel] M3Config In-Reply-To: <1249020635.2801.476.camel@faramir.m3w.org> References: <1248992439.2801.9.camel@faramir.m3w.org> <1249020635.2801.476.camel@faramir.m3w.org> Message-ID: <1249044221.27649.235.camel@faramir.m3w.org> Uhoh. I would like to use MxConfig.Get(), ok. It is in m3quake. Depending on m3middle. Depending on sysutils. Looks a bit too heavy for simple "where is ...?" processing. Can this logic be moved so I don't have to dynamicaly link large chunk of compiler code in every program using this functionality? TIA, dd On Fri, 2009-07-31 at 08:10 +0200, Dragi?a Duri? wrote: > Of course I do not insist. I need function, form is what someone with > wider insight can decide much better. It's a bit... unusual... to depend > on m3quake, but then... it's probably very unusual to read .M3WEB's too. > I'll try it, thanks. > > dd > > On Fri, 2009-07-31 at 01:30 +0000, Jay K wrote: > > It was partly unsupportable and you can trivially replace it with MxConfig. > > Please try that -- MxConfig. MxConfig.Get() I recall. > > > > > > We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > From: dragisha at m3w.org > > > To: jay.krell at cornell.edu > > > Date: Fri, 31 Jul 2009 00:20:39 +0200 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] M3Config > > > > > > I have code reading data structure information from .M3WEB files.... And > > > that code used M3Config for obvious things... Now when you killed it, > > > how I am supposed (in portable way) to find these files? :) > > > > > > TIA, > > > dd > > > > > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > > >> So..I was wondering..what were the original authors thinking? > > >> > > >> And there was that comment about the file containing the data upon > > >> install. > > >> Which seemed wrong to me. > > >> > > >> They were probably thinking of the way 3.6 was packaged and > > >> distributed -- everyone built the system from source, upon building > > >> m3build/m3ship from C and m3 from assembly. > > >> > > >> That isn't a bad model, but we probably want both. > > >> > > >> There are at least three times the paths can be computed/recorded: > > >> 1) when you build libm3 > > >> 2) when you install libm3 > > >> #1 and #2 may or may not be close in time and have the same result. > > >> 3) by parsing cm3.cfg as needed > > >> > > >> #2 is more efficient than #3 and matches the old code, but #3 is how I > > >> left it, probably ok. > > >> > > >> - Jay > > >> > > > -- > > > Dragi?a Duri? > > > -- Dragi?a Duri? From hendrik at topoi.pooq.com Fri Jul 31 15:13:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 09:13:41 -0400 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> <20090731123115.GA17620@topoi.pooq.com> Message-ID: <20090731131340.GC17620@topoi.pooq.com> On Fri, Jul 31, 2009 at 12:36:26PM +0000, Jay K wrote: > > We should be a little careful with ARM_LINUX imho. And MIPS_LINUX. > > > Those target name might be ok, and they'd refer to Linux 2.6+ with glibc. > Many ARM and MIPS Linux systems aren't that. > > > ARM has old ABI and new ABI, at the kernel level. Nokia uses the new ABI, I believe. Maemo, its OS, is debian-derived, but it is *not* Debian. Though it is possible to set it up to use Debian user-space in a chroot on the maemo kernel. > It it also common to replace glibc with uclibc. > I don't know if they are binary compatible or not. > My Linux/arm machine/device is old ABI and uclibc. So it's probably not. > It seems that if you are building your own kernel, > it is trivial to use old ABI. It isn't like it is incompatible > with new hardware, I think. I think whoever put together > the Western Digital MyBook World Edition just took the default. > > > MIPS..well, I was surprised. I installed "Tomato" on my router. > It is /very/ low end, but it does have a builtin SMB client, therefore > it has infinite diskspace. > It uses Linux 2.4, and I think/assume uclibc. > > > MIPS also has big and little endian and I don't know if either is > more common or if it is an even split. I know the hardware has that option -- it's controlled by a bit in some processor register. I remember wonderein, years ago, whether the OS allowed one to set that on a per-process basis, or even more finely. The situation reminds me of the IBM 360, which had a similar bit to control whether its native instructino set would support decimal operations in ASCII or in EBCDIC. But because changing that bit was a privileged operation, no one really got to set it, and everything was always EBCDIC. With the 370, I believe IBM discontinued the ASCII option. No one had ever used it. -- hendrik From hosking at cs.purdue.edu Fri Jul 31 15:42:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 09:42:19 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: I don't care if future versions are not compilable with old cm3. But, vice versa, old versions should always be compilable with new cm3. My gut feelings run along the lines of what Randy has said. I do think that the average user should accept std as the install, while min is for power-users who know what they are doing. Does that jive with other people's expectations? On 31 Jul 2009, at 03:39, Jay K wrote: > > I'm sorry but I'm feeling very impatient... > > > > >> Namely, that "min" is the smallest distribution we plan to make >> available > > > Ok, that is clearer. > That is not scientific but a matter of a decision. > We could decide that min==std, not a bad decision really, since it > gives users fewer confusing choices, and provides one package per > platform, with no overlap. > On the downside, it isn't small and some people might say we look fat. > > > > >> My "opinion" is that "min" should contain only what is >> necessary for a working cm3 compiler > > > Now you have made a policy decision. An acceptable one. > But not necessarily how it should and not necessarily consistent > with some other things. > > >> Anything added to "min" that isn't necessary to accomplish >> building the remaining packages would be considered superfluous, >> in my opinion. > >> Some amount of superfluous on a given platform may be >> tolerable in order to reach consistency among all supported >> platforms regarding the composition of "min". Thus, >> if cm3cg is needed for "min" on some platforms, but not all, >> it is tolerable (IMO) to make it a standard component of "min" >> on all platforms. > > > cm3cg doesn't really make sense on NT386 though. > I've probably thrown it in somewhat by accident. > If it is there, it'll depend on Cygwin, and NT386 will just ignore > it completely, except for wasted diskspace, network traffic. > > >> WRT#4, although doc may not be needed to run cm3, it is needed >> for folks to reference and understand cm3. > > > Now you are expanding the definition. The documentation is all > online too. > I'm certainly fine with including the documentation. Just be clear > that "min"'s definition is expanding. > (I'm fine with not distributing min at all, as I said, min==std?) > > >> The naive user new to cm3 normally expects to get some documentation. > > I don't expect naive users to build cm3 themselves. > This is in fact a reason not to provide min at all, but std. > That way, the naive person who thinks he is expert won't make a > mistake. > Really. On the other hand, there are the masochists among us who use > the Debian "netinst" and chose no additional packages during setup. :) > If one has the time/patience, it can also be educational to create > arbitrary difficult situations and work your way out of them. Really. > (Why does anyone use Linux after all?) > > >> If the default is no documentation, how does the poor sap know >> how to get the documentation and install it? > > > Poor saps should use "std", not "min". Right? > What is "min"? The "minimum" distribution that is useful for > "everyone" or the minimal distribution to build cm3? > > > I should correct myself by the way. > cm3cg is not needed in "min". > It is "easily" just not quickly built from just cm3 and the m3-sys/ > m3cc part of the tree, and really cm3 is hardly needed for that (but > cm3 is definitely needed for building everything else, so needed > overall). > > >> [Jay] docs/examples I think it was >> The "typical" installation choice should install it by default. > > > "typical" or "min"? > > >> WRT#11, now we are finally getting to the meat of my questions. So, >> if I understand you correctly, you are saying that building the "min" >> group of packages does not recreate for me exactly what > > > You must start with a prebuilt compiler (cm3). > Whether you rebuild the compiler or not is somewhat a matter of taste. > Indeed it is more tasteful to build it. > In which case indeed, you need to build "front", but "front" need > not be in the distribution. "front" is in fact basically just cm3, > and I think cm3cg. > > > Again again again, the "package groups" are just a redundant > encoding of the dependency tree that is encoded in the m3makefiles. > We could the entire scripts directory and pretty much everything > would work about the same. It would just be a little tedious. > > > More and more I think we should actually delete a lot of this. > We should keep the PKGS file, or make cm3 able to figure it out, and > the "scripts" should just accept an end goal -- "cm3", and it should > read the m3makefiles and build the dependency graph from the buttom > up to the goal. > > > There could be special goal called "all", AND we could have the > broken m3makefiles all filter themselves out. > > Perhaps a special group called "test", whose membership is implied > by path? > > > But now, you see, the more of these features I add, the more I'm > back to reinventing these minor little scripts and package groups > that we have. > > > But do you see, that these aren't sort of all that significant? > What you need to build is whatever m3makefiles lists in imports, and > follow the transitive closure. And cm3cg is sort of different -- > because it isn't a linked/library dependency, but rather because the > config files tries to run a program (cm3cg) and that program needs > to therefore exist somewhere. That is, the linked/library > dependencies are encoded in a nice declarative way in the > m3makefiles but the dependency on cm3cg is encoded in an imperative > way. > > > > > My interpretion of "min" has been roughly a minimal distribution > that one can start with in order to build cm3, EVEN IF old cm3 > cannot build m3core and libm3 from current source. The part I don't > understand is that last point -- is it considered a recurring > problem? Where is the line? What about sysutils? Is sysutils > expected to be forever bound to be buildable by arbitrarily old > compilers? > > > Do we make a release shortly any such incompatibilities occur? > Do we in fact not cater to such incompatibilities, and "min" > therefore does NOT include m3core and libm3? > > > Historically there was actually a more recurring problem here, > around the list of targets. That is gone now. However there are > still occasional problems like LONGINT. It seems to me this is > somewhat of a problem of predicting the future, which is impossible. > But also taking out very cheap insurance against the only fairly > small number of bad futures. That is, throwing in m3core and libm3 > is cheap, and it allows for future versions to not be compilable > with old cm3, and that not being a big deal. > This is all a bit gray and heuristic however. > > > If today you start with a 5.4 or such cm3, indeed, you cannot build > m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3. > > > If you start with yesterday's cm3 however, you can build today's > entire system, without also having yesterday's m3core/libm3 (nor > cm3cg). > > > See? It depends. > And mitigating the worst case is perhaps worthwhile and cheap. > > > And it depends because the system is necessarily circular. > ("necessary" because the compiler is written in Modula-3) > Breaking circular dependencies requires cheating. > Changes in circular graphs can require cheating differently. > > > > If we do this, it is probably a good idea to also include sysutils > in min -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 31 15:42:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 09:42:33 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <767A3979-1061-449C-8B28-900EE49D2848@cs.purdue.edu> Correct. On 31 Jul 2009, at 03:59, Jay K wrote: > > [truncated right about here..] > > > If we do this, it is probably a good idea to also include sysutils > in min -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 31 16:05:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 16:05:46 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> Quoting Tony Hosking : > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Sorry, I only now caught up with _some_ of the mails on the m3devel list. Too much traffic for me to digest. I gather there's been a long discussion that `min' is not really useful as it is not enough to build the system. When we started the cm3 5 business many years ago with lots of uncompilable sources from Farshad Nayeri, we invented the following sets of packages: all - obvious meaning. most packages did not compile at all. std - the set of packages shipped as compilable and usable with every new release core - a useful but small set of packages including everything to bootstrap the compiler boot - the minimal set to bootstrap the compiler min - the minimal set useful for anyone (not wanting to compiler cm3) As of today, std = all, and boot isn't used any more as far as a I see. I'm fine with any changes in the pragmatics or intended use of these package sets though. Just wanted to throw in some history. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Jul 31 17:13:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:13:58 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> Message-ID: <20090731151357.GA18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > >I don't care if future versions are not compilable with old cm3. But, > >vice versa, old versions should always be compilable with new cm3. > > > >My gut feelings run along the lines of what Randy has said. I do > >think that the average user should accept std as the install, while > >min is for power-users who know what they are doing. Does that jive > >with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. Is that becaouse no one ever boots the compiler any more? Or because there are better ways to do it? -- hendrik > > I'm fine with any changes in the pragmatics or intended use of these > package sets though. Just wanted to throw in some history. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Fri Jul 31 17:19:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:19:15 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <20090731151914.GB18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 09:42:19AM -0400, Tony Hosking wrote: > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Debian treats packages that share code as an anathema. So if there's a min package, they'd insist that std has the min parts removed from it, and depend on the min package instead of including it. Of course, the package description of the min package could gently advise potential users that they probably want to use the 'std' package instead... -- hendrik From hendrik at topoi.pooq.com Fri Jul 31 17:20:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:20:48 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731151357.GA18289@topoi.pooq.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> Message-ID: <20090731152047.GC18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > > >I don't care if future versions are not compilable with old cm3. But, > > >vice versa, old versions should always be compilable with new cm3. > > > > > >My gut feelings run along the lines of what Randy has said. I do > > >think that the average user should accept std as the install, while > > >min is for power-users who know what they are doing. Does that jive > > >with other people's expectations? > > > > Sorry, I only now caught up with _some_ of the mails on the m3devel > > list. Too much traffic for me to digest. > > > > I gather there's been a long discussion that `min' is not really > > useful as it is not enough to build the system. When we started > > the cm3 5 business many years ago with lots of uncompilable sources > > from Farshad Nayeri, we invented the following sets of packages: > > > > all - obvious meaning. most packages did not compile at all. > > std - the set of packages shipped as compilable and usable with > > every new release > > core - a useful but small set of packages including everything to > > bootstrap the compiler > > boot - the minimal set to bootstrap the compiler > > min - the minimal set useful for anyone (not wanting to compiler cm3) > > > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik I guess I should mention that ebian is perfectly happy if one source parckage (possibly the entire working cm3 system) generates multiple binary packages. -- hendrik From rcoleburn at scires.com Fri Jul 31 17:33:09 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 11:33:09 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content Message-ID: <4A72D418020000D70005DF1C@scires.com> Jay: The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. Regards, Randy Coleburn >>> Jay K 07/31/09 2:51 AM >>> BUILD_DIR is defined. cm3 requires it too. It just isn't necessarily defined in the toplevel file, but in a file that gets included. > PKG_USE I believe that is also defined but I'll check. > DOC_INSTALL I doubt that is defined because I never saw it used. I can add it back. > INSTALL_ROOT That is certainly defined, and very important. > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR These are probably also not defined because I never saw them used. I can add them back..but they are actually very user specific. I can add defaults like: BROWSER=iexplore.exe EDITOR=notepad.exe BROWSER=firefox-bin EDITOR=/usr/bin/vi I'll do a little reserach and try to find defaults that work. - Jay ________________________________ > Date: Fri, 31 Jul 2009 01:05:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content > > > > > > > > Jay et al: > > > > On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. > > > > cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". > > > > I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. > > > > At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. > > > > In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. > > > > In particular, these are: > > BUILD_DIR > > PKG_USE > > DOC_INSTALL > > INSTALL_ROOT > > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR > > > > If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. > > > > I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. > > > > It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. > > > > Regards, > > Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 17:27:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 15:27:57 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090731152047.GC18289@topoi.pooq.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> Message-ID: What does it mean to boot the compiler? I build the compiler from nothing but the compiler itself, and config files, and C compiler and linker, cvs to get all the source. That's not nothing, but it about the smallest start you can have, unless you rewrite the compiler in C, then you can start without the Modula-3 compiler. But at certain points in time this would not work, due to m3core and/or libm3 problems. It does work today. Is that booting? In future I'd like to dynamically link cm3, so I'd start with cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" dependencies. Many other systems do dynamically link to this extent and we can to. I'm not just being obnoxious. Really, what does it mean? Should we just ship std and that's it? And even drop the name from it? cm3-PPC_LINUX-5.8.2.tar.gz ? (No need to say "POSIX", it is redundant). Just one download per platform? Not a big matrix of packages to test? Or do we look too fat in that packaging? :) Will too much stuff confuse users? Or mitigate the bulk with a little documentation/tutorial? Something like this: There are many libraries and packages. You do not need to worry about them. Here is hello world for a command line program: ... And for a gui program: ... And a minimal sample interoperating with C: ... And a minimal sample using Modula-3's RPC called "network objects": ... CM3 4.1 had some like this that were nice, presumably we have them. - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>> Quoting Tony Hosking : >>> >>>>I don't care if future versions are not compilable with old cm3. But, >>>>vice versa, old versions should always be compilable with new cm3. >>>> >>>>My gut feelings run along the lines of what Randy has said. I do >>>>think that the average user should accept std as the install, while >>>>min is for power-users who know what they are doing. Does that jive >>>>with other people's expectations? >>> >>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>> list. Too much traffic for me to digest. >>> >>> I gather there's been a long discussion that `min' is not really >>> useful as it is not enough to build the system. When we started >>> the cm3 5 business many years ago with lots of uncompilable sources >>> from Farshad Nayeri, we invented the following sets of packages: >>> >>> all - obvious meaning. most packages did not compile at all. >>> std - the set of packages shipped as compilable and usable with >>> every new release >>> core - a useful but small set of packages including everything to >>> bootstrap the compiler >>> boot - the minimal set to bootstrap the compiler >>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>> >>> As of today, std = all, and boot isn't used any more as far as a I see. >> >> Is that becaouse no one ever boots the compiler any more? Or because >> there are better ways to do it? >> >> -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > From jay.krell at cornell.edu Fri Jul 31 17:31:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 15:31:14 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content In-Reply-To: <4A72D418020000D70005DF1C@scires.com> References: <4A72D418020000D70005DF1C@scires.com> Message-ID: MxConfig.Get() is able to retrieve the included part. MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. It is exactly the same code as the compiler uses. The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. Due to missing variables MxConfig would kind of give up and return NULL. I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. Maybe we should work this into the .msi?? - Jay ________________________________ > Date: Fri, 31 Jul 2009 11:33:09 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. > > > > I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. > > > > Regards, > > Randy Coleburn > >>>> Jay K 07/31/09 2:51 AM>>> > > BUILD_DIR is defined. > cm3 requires it too. > It just isn't necessarily defined in the toplevel file, but in a file that gets included. > >> PKG_USE > > > I believe that is also defined but I'll check. > > >> DOC_INSTALL > > I doubt that is defined because I never saw it used. I can add it back. > > >> INSTALL_ROOT > > > That is certainly defined, and very important. > > >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR > > > These are probably also not defined because I never saw them used. > I can add them back..but they are actually very user specific. > I can add defaults like: > > BROWSER=iexplore.exe > EDITOR=notepad.exe > > BROWSER=firefox-bin > EDITOR=/usr/bin/vi > > > I'll do a little reserach and try to find defaults that work. > > > - Jay > > ________________________________ >> Date: Fri, 31 Jul 2009 01:05:45 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >> >> >> >> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >> >> >> >> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >> >> >> >> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >> >> >> >> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >> >> >> >> In particular, these are: >> >> BUILD_DIR >> >> PKG_USE >> >> DOC_INSTALL >> >> INSTALL_ROOT >> >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR >> >> >> >> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >> >> >> >> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >> >> >> >> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >> >> >> >> Regards, >> >> Randy Coleburn From hendrik at topoi.pooq.com Fri Jul 31 17:51:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:51:05 -0400 Subject: [M3devel] Platform names Message-ID: <20090731155105.GA18363@topoi.pooq.com> Just to make life complicated, Debian has announced that the next release (squeeze, once it's stable) will have multiarch support (which means we'll be able to run 32-bit and 64-bit programs on AMD64), and that it will support both the Linux and BSD kernels. So Debian won't necessarily be a Linux system any more. -- hendrik From rcoleburn at scires.com Fri Jul 31 18:01:24 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 12:01:24 -0400 Subject: [M3devel] package groups question Message-ID: <4A72DD14020000D70005DF68@scires.com> Olaf: Thanks for the brief history lesson. These definitions coincide with my recollection. >From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". My problem has been a misunderstanding of "min", having thought that I could use min to bootstrap the compiler. My bad here. Jay has been talking about tracing graphs and figuring out everything from m3makefiles. In a distributed development environment, I'm not sure this approach works well. I am fine with continued use of PkgInfo.txt. I've been able to generate scripts using it with relative ease. For this release, I think we have at least 2 groups of "users" to be supported: 1. The power users who know enough to tweak the details of their installation, rebuild the compiler, etc. etc. They want the flexibility to tailor everything. You, Jay, Tony, etc. are in this camp. 2. The average or even new user who just wants a simple install that works out-of-the-box. He doesn't want anything complicated to install. He probably won't rebuild the compiler and is content to update his system whenever a new release is made. Obviously, folks from camp #2 may promote themselves to camp #1 after sufficient experience. If we agree on these two camps, I think that your definition of "min" is ok, but I would argue that "std" should include the documentation, examples, and pre-built binaries and sources for all packages known to work on all platforms. That would allow "std" to satisfy camp #2. Thus, "std" should be the recommended option for most users. The power users in camp #1 can start with either "min" or "std" and they have the knowledge to transform either of these into "all" or whatever sub-grouping they want. I appreciate everything Jay is doing, but I think he is so deep in the details right now, and also still looking forward past this release, that his responses to my questions aren't really answering what I'm trying to discuss regarding nailing down this release. Sure, with complete knowledge you can do most anything, but I'm looking at what I can do using cm3ide and the cm3.exe builder/compiler and the "min" and "std" releases using the default install locations. I'm heading south for a family reunion. I'll try to check email some this weekend, but it will be sparse. As soon as I can, I'll try to put some of what I've gleaned in a text file we can add to the documentation/web. Regards, Randy Coileburn >>> Olaf Wagner 07/31/09 10:08 AM >>> Quoting Tony Hosking : > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Sorry, I only now caught up with _some_ of the mails on the m3devel list. Too much traffic for me to digest. I gather there's been a long discussion that `min' is not really useful as it is not enough to build the system. When we started the cm3 5 business many years ago with lots of uncompilable sources from Farshad Nayeri, we invented the following sets of packages: all - obvious meaning. most packages did not compile at all. std - the set of packages shipped as compilable and usable with every new release core - a useful but small set of packages including everything to bootstrap the compiler boot - the minimal set to bootstrap the compiler min - the minimal set useful for anyone (not wanting to compiler cm3) As of today, std = all, and boot isn't used any more as far as a I see. I'm fine with any changes in the pragmatics or intended use of these package sets though. Just wanted to throw in some history. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 18:09:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 12:09:57 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content Message-ID: <4A72DF15020000D70005DF87@scires.com> Jay: The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly. I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.) Let me know if you have any ideas on why Vista is different in this regard. Regards, Randy >>> Jay K 07/31/09 11:33 AM >>> MxConfig.Get() is able to retrieve the included part. MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. It is exactly the same code as the compiler uses. The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. Due to missing variables MxConfig would kind of give up and return NULL. I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. Maybe we should work this into the .msi?? - Jay ________________________________ > Date: Fri, 31 Jul 2009 11:33:09 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. > > > > I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. > > > > Regards, > > Randy Coleburn > >>>> Jay K 07/31/09 2:51 AM>>> > > BUILD_DIR is defined. > cm3 requires it too. > It just isn't necessarily defined in the toplevel file, but in a file that gets included. > >> PKG_USE > > > I believe that is also defined but I'll check. > > >> DOC_INSTALL > > I doubt that is defined because I never saw it used. I can add it back. > > >> INSTALL_ROOT > > > That is certainly defined, and very important. > > >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR > > > These are probably also not defined because I never saw them used. > I can add them back..but they are actually very user specific. > I can add defaults like: > > BROWSER=iexplore.exe > EDITOR=notepad.exe > > BROWSER=firefox-bin > EDITOR=/usr/bin/vi > > > I'll do a little reserach and try to find defaults that work. > > > - Jay > > ________________________________ >> Date: Fri, 31 Jul 2009 01:05:45 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >> >> >> >> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >> >> >> >> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >> >> >> >> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >> >> >> >> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >> >> >> >> In particular, these are: >> >> BUILD_DIR >> >> PKG_USE >> >> DOC_INSTALL >> >> INSTALL_ROOT >> >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR >> >> >> >> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >> >> >> >> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >> >> >> >> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >> >> >> >> Regards, >> >> Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:21:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:21:22 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content In-Reply-To: <4A72DF15020000D70005DF87@scires.com> References: <4A72DF15020000D70005DF87@scires.com> Message-ID: Randy, when you test start /wait on Vista (or XP for that matter), make sure first that there are no instances of iexplore.exe in taskmgr. I bet what is happening is that the new iexplore.exe you ran actually did exit. Each user should probably have his own web server? Or, what is wrong with keeping the web server running even after the browser exits? I will double check BUILD_DIR, but the code is shared with cm3. How about the other variables? Vista vs. XP should not matter here. - Jay ________________________________ > Date: Fri, 31 Jul 2009 12:09:57 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly. > > > > I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.) > > > > Let me know if you have any ideas on why Vista is different in this regard. > > > > Regards, > > Randy > >>>> Jay K 07/31/09 11:33 AM>>> > > MxConfig.Get() is able to retrieve the included part. > MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. > It is exactly the same code as the compiler uses. > The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. > Due to missing variables MxConfig would kind of give up and return NULL. > > > I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. > > > Maybe we should work this into the .msi?? > > > - Jay > > > ________________________________ >> Date: Fri, 31 Jul 2009 11:33:09 -0400 >> From: rcoleburn at scires.com >> To: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content >> >> >> >> Jay: >> >> >> >> The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. >> >> >> >> I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay K 07/31/09 2:51 AM>>> >> >> BUILD_DIR is defined. >> cm3 requires it too. >> It just isn't necessarily defined in the toplevel file, but in a file that gets included. >> >>> PKG_USE >> >> >> I believe that is also defined but I'll check. >> >> >>> DOC_INSTALL >> >> I doubt that is defined because I never saw it used. I can add it back. >> >> >>> INSTALL_ROOT >> >> >> That is certainly defined, and very important. >> >> >>> INITIAL_CM3_IDE_BROWSER >>> >>> INITIAL_CM3_IDE_EDITOR >> >> >> These are probably also not defined because I never saw them used. >> I can add them back..but they are actually very user specific. >> I can add defaults like: >> >> BROWSER=iexplore.exe >> EDITOR=notepad.exe >> >> BROWSER=firefox-bin >> EDITOR=/usr/bin/vi >> >> >> I'll do a little reserach and try to find defaults that work. >> >> >> - Jay >> >> ________________________________ >>> Date: Fri, 31 Jul 2009 01:05:45 -0400 >>> From: rcoleburn at scires.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >>> >>> >>> >>> >>> >>> >>> >>> Jay et al: >>> >>> >>> >>> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >>> >>> >>> >>> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >>> >>> >>> >>> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >>> >>> >>> >>> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >>> >>> >>> >>> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >>> >>> >>> >>> In particular, these are: >>> >>> BUILD_DIR >>> >>> PKG_USE >>> >>> DOC_INSTALL >>> >>> INSTALL_ROOT >>> >>> INITIAL_CM3_IDE_BROWSER >>> >>> INITIAL_CM3_IDE_EDITOR >>> >>> >>> >>> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >>> >>> >>> >>> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >>> >>> >>> >>> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >>> >>> >>> >>> Regards, >>> >>> Randy Coleburn From wagner at elegosoft.com Fri Jul 31 18:27:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 18:27:47 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> Message-ID: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> I meant getting the first instance of cm3 5.1 run on a certain platform. And there was of course a first platform. We used the SRC compiler, the cm3 4.1 from Critical Mass, and the PM3 compiler on different platforms. Later we used cross-compilation almost exclusively. I assume that cross-compilation support has improved dramatically with all your changes. Olaf Quoting Jay K : > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- >> Date: Fri, 31 Jul 2009 11:20:48 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>> Quoting Tony Hosking : >>>> >>>>> I don't care if future versions are not compilable with old cm3. But, >>>>> vice versa, old versions should always be compilable with new cm3. >>>>> >>>>> My gut feelings run along the lines of what Randy has said. I do >>>>> think that the average user should accept std as the install, while >>>>> min is for power-users who know what they are doing. Does that jive >>>>> with other people's expectations? >>>> >>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>> list. Too much traffic for me to digest. >>>> >>>> I gather there's been a long discussion that `min' is not really >>>> useful as it is not enough to build the system. When we started >>>> the cm3 5 business many years ago with lots of uncompilable sources >>>> from Farshad Nayeri, we invented the following sets of packages: >>>> >>>> all - obvious meaning. most packages did not compile at all. >>>> std - the set of packages shipped as compilable and usable with >>>> every new release >>>> core - a useful but small set of packages including everything to >>>> bootstrap the compiler >>>> boot - the minimal set to bootstrap the compiler >>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>> >>>> As of today, std = all, and boot isn't used any more as far as a I see. >>> >>> Is that becaouse no one ever boots the compiler any more? Or because >>> there are better ways to do it? >>> >>> -- hendrik >> >> I guess I should mention that ebian is perfectly happy if one source >> parckage (possibly the entire working cm3 system) generates multiple >> binary packages. >> >> -- hendrik >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jul 31 18:31:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 12:31:49 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add? On 31 Jul 2009, at 12:27, Olaf Wagner wrote: > I meant getting the first instance of cm3 5.1 run on a certain > platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >> dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >>> wrote: >>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>> Quoting Tony Hosking : >>>>> >>>>>> I don't care if future versions are not compilable with old >>>>>> cm3. But, >>>>>> vice versa, old versions should always be compilable with new >>>>>> cm3. >>>>>> >>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>> think that the average user should accept std as the install, >>>>>> while >>>>>> min is for power-users who know what they are doing. Does that >>>>>> jive >>>>>> with other people's expectations? >>>>> >>>>> Sorry, I only now caught up with _some_ of the mails on the >>>>> m3devel >>>>> list. Too much traffic for me to digest. >>>>> >>>>> I gather there's been a long discussion that `min' is not really >>>>> useful as it is not enough to build the system. When we started >>>>> the cm3 5 business many years ago with lots of uncompilable >>>>> sources >>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>> >>>>> all - obvious meaning. most packages did not compile at all. >>>>> std - the set of packages shipped as compilable and usable with >>>>> every new release >>>>> core - a useful but small set of packages including everything to >>>>> bootstrap the compiler >>>>> boot - the minimal set to bootstrap the compiler >>>>> min - the minimal set useful for anyone (not wanting to compiler >>>>> cm3) >>>>> >>>>> As of today, std = all, and boot isn't used any more as far as a >>>>> I see. >>>> >>>> Is that becaouse no one ever boots the compiler any more? Or >>>> because >>>> there are better ways to do it? >>>> >>>> -- hendrik >>> >>> I guess I should mention that ebian is perfectly happy if one source >>> parckage (possibly the entire working cm3 system) generates multiple >>> binary packages. >>> >>> -- hendrik >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:35:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:35:19 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: I actually think cross compilation support might have been very good in the first place. :) In either case, yes, cross compilation support is good and easy now, if it wasn't earlier. I only ever cross compile cm3 itself though, not the entire system. Mainly what I did is some automation in pylib.py, which isn't all it should be, but again, enough for cm3. It's arguably not much more than your scripts. Oh, well, I also changed cm3.cfg to probe around for a reasonable cm3cg, so I could stop constantly overwriting the One /cm3/bin/cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. Really we should ship to /cm3/bin/host/target/cm3cg probably. Cross compiling the entire system will be useful for distribution purposes, but not in this release probably. It will enable us to claim to build a distribution for some target, without actually having the target available..which is a little bit dishonest, granted, you couldn't have run the tests. However it also allows cross building the entire system for slow targets, that you do have and will run the tests on, e.g. iphone, mips network router, my SGI machine, etc. If you booted from other distributions...these package groups refer to something in them?? - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 18:27:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>> Quoting Tony Hosking : >>>>> >>>>>> I don't care if future versions are not compilable with old cm3. But, >>>>>> vice versa, old versions should always be compilable with new cm3. >>>>>> >>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>> think that the average user should accept std as the install, while >>>>>> min is for power-users who know what they are doing. Does that jive >>>>>> with other people's expectations? >>>>> >>>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>>> list. Too much traffic for me to digest. >>>>> >>>>> I gather there's been a long discussion that `min' is not really >>>>> useful as it is not enough to build the system. When we started >>>>> the cm3 5 business many years ago with lots of uncompilable sources >>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>> >>>>> all - obvious meaning. most packages did not compile at all. >>>>> std - the set of packages shipped as compilable and usable with >>>>> every new release >>>>> core - a useful but small set of packages including everything to >>>>> bootstrap the compiler >>>>> boot - the minimal set to bootstrap the compiler >>>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>>> >>>>> As of today, std = all, and boot isn't used any more as far as a I see. >>>> >>>> Is that becaouse no one ever boots the compiler any more? Or because >>>> there are better ways to do it? >>>> >>>> -- hendrik >>> >>> I guess I should mention that ebian is perfectly happy if one source >>> parckage (possibly the entire working cm3 system) generates multiple >>> binary packages. >>> >>> -- hendrik >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 31 18:43:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:43:04 +0000 Subject: [M3devel] package groups question In-Reply-To: <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> Message-ID: That reminds me, darn it.. Yes I think the INTEGER/FLOAT things are ok now. I had hit problems in float and/or double bootstrapping where host and target differed in endian and fixed it. There were also 32bit/64bit problems there maybe, also now believed fixed. And gcc used to be partly to blame for problems here, but has been fixed. I even suggested they rev the documented caveats about building for Alpha and I think they did. I do bootstrap from host-generated .s files. I understand you could bootstrap from .mc files instead. Maybe even textual ones? That you use as a distribution format? Advantages/disadvantages? Minor one is that you'd have to build m3cc without the small aid of cm3..not a big deal, just configure -disable-bootstrap -disable-multilibs && make and ignore all my little tweaks in the m3makefile. If not textual, mc files are less readable..but assembly is unreadable to most people anyway.. There are bugs here though. - I left in the hack you didn't like in order to bootstrap from 32bit to 64bit, where TEXTs are limited to 4gig, rather than some much larger value on 64bit systems. The front end should be doing target math there not host math. - You can't bootstrap from 64bit to 32bit due to some similar small bug in the front end. Probably also a target math vs. host math thing. We already have the code to simulate target math, we just have to use it a little more. (This is what gcc now uses gmp/mpfr for presumably, like wrt constant propagation.) - Jay ________________________________ > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Fri, 31 Jul 2009 12:31:49 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add? > > On 31 Jul 2009, at 12:27, Olaf Wagner wrote: > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K>: > > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hosking at cs.purdue.edu Fri Jul 31 18:46:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 12:46:26 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: Agreed, cross-compilation only needed for cm3 itself. PM3 used to distribute the derived .s files for each platform and installation required building cm3 from those. That way there was no need to deliver an executable cm3. It was all source. On 31 Jul 2009, at 12:35, Jay K wrote: > > I actually think cross compilation support might have been very good > in the first place. :) > In either case, yes, cross compilation support is good and easy now, > if it wasn't earlier. > I only ever cross compile cm3 itself though, not the entire system. > Mainly what I did is some automation in pylib.py, which isn't all it > should be, but again, enough for cm3. > It's arguably not much more than your scripts. > > > Oh, well, I also changed cm3.cfg to probe around for a reasonable > cm3cg, so I could stop constantly overwriting the One /cm3/bin/ > cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. > Really we should ship to /cm3/bin/host/target/cm3cg probably. > > > Cross compiling the entire system will be useful for distribution > purposes, but not in this release probably. > It will enable us to claim to build a distribution for some target, > without actually having the target available..which is a little bit > dishonest, granted, you couldn't have run the tests. > > > However it also allows cross building the entire system for slow > targets, that you do have and will run the tests on, e.g. iphone, > mips network router, my SGI machine, etc. > > > If you booted from other distributions...these package groups refer > to something in them?? > > > - Jay > > ---------------------------------------- >> Date: Fri, 31 Jul 2009 18:27:47 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> I meant getting the first instance of cm3 5.1 run on a certain >> platform. >> And there was of course a first platform. We used the SRC compiler, >> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >> platforms. Later we used cross-compilation almost exclusively. >> >> I assume that cross-compilation support has improved dramatically >> with all your changes. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> What does it mean to boot the compiler? >>> >>> >>> I build the compiler from nothing but the compiler itself, >>> and config files, and C compiler and linker, cvs >>> to get all the source. >>> That's not nothing, but it about the smallest start you can have, >>> unless you rewrite the compiler in C, then you can start without >>> the Modula-3 compiler. But at certain points in time this >>> would not work, due to m3core and/or libm3 problems. >>> It does work today. >>> >>> >>> Is that booting? >>> >>> >>> In future I'd like to dynamically link cm3, so I'd start with >>> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >>> dynamic" >>> dependencies. Many other systems do dynamically link to this extent >>> and we can to. >>> >>> >>> I'm not just being obnoxious. >>> Really, what does it mean? >>> >>> >>> Should we just ship std and that's it? >>> And even drop the name from it? >>> cm3-PPC_LINUX-5.8.2.tar.gz ? >>> >>> >>> (No need to say "POSIX", it is redundant). >>> Just one download per platform? >>> Not a big matrix of packages to test? >>> >>> >>> Or do we look too fat in that packaging? :) >>> >>> >>> Will too much stuff confuse users? >>> >>> >>> Or mitigate the bulk with a little documentation/tutorial? >>> >>> >>> Something like this: >>> >>> There are many libraries and packages. >>> You do not need to worry about them. >>> Here is hello world for a command line program: >>> ... >>> And for a gui program: >>> ... >>> And a minimal sample interoperating with C: >>> ... >>> And a minimal sample using Modula-3's RPC called "network objects": >>> ... >>> >>> CM3 4.1 had some like this that were nice, presumably we have them. >>> >>> - Jay >>> >>> >>> >>> >>> ---------------------------------------- >>>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>>> From: hendrik at topoi.pooq.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] package groups question >>>> >>>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >>>> wrote: >>>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> I don't care if future versions are not compilable with old >>>>>>> cm3. But, >>>>>>> vice versa, old versions should always be compilable with new >>>>>>> cm3. >>>>>>> >>>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>>> think that the average user should accept std as the install, >>>>>>> while >>>>>>> min is for power-users who know what they are doing. Does that >>>>>>> jive >>>>>>> with other people's expectations? >>>>>> >>>>>> Sorry, I only now caught up with _some_ of the mails on the >>>>>> m3devel >>>>>> list. Too much traffic for me to digest. >>>>>> >>>>>> I gather there's been a long discussion that `min' is not really >>>>>> useful as it is not enough to build the system. When we started >>>>>> the cm3 5 business many years ago with lots of uncompilable >>>>>> sources >>>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>>> >>>>>> all - obvious meaning. most packages did not compile at all. >>>>>> std - the set of packages shipped as compilable and usable with >>>>>> every new release >>>>>> core - a useful but small set of packages including everything to >>>>>> bootstrap the compiler >>>>>> boot - the minimal set to bootstrap the compiler >>>>>> min - the minimal set useful for anyone (not wanting to >>>>>> compiler cm3) >>>>>> >>>>>> As of today, std = all, and boot isn't used any more as far as >>>>>> a I see. >>>>> >>>>> Is that becaouse no one ever boots the compiler any more? Or >>>>> because >>>>> there are better ways to do it? >>>>> >>>>> -- hendrik >>>> >>>> I guess I should mention that ebian is perfectly happy if one >>>> source >>>> parckage (possibly the entire working cm3 system) generates >>>> multiple >>>> binary packages. >>>> >>>> -- hendrik >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:49:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:49:41 +0000 Subject: [M3devel] "how to build a distribution" Message-ID: On this matter there's actually more stuff worth mentioning. Like, you always need various packages/libraries/tools that are often not in default minimal OS installs. ODBC, X Windows, Postgres, bc, flex, bison, gcc, make, cvs, opengl, etc. None of those are in the default Debian netinst for example. And esp. the first few are not in many systems' default installations. You don't need any of these, except for gcc basically, to use Modula-3. But if you want to include all of "std", you need the C headers and/or librarie (often just libraries). I never was able to find opengl for I386_DARWIN (not MacOSX). - Jay From jay.krell at cornell.edu Fri Jul 31 18:53:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:53:05 +0000 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: I like that PM3/SRC model, just haven't (re)implemented it yet. In that model I believe we'd have binary and source distributions. binary for the less patient. Source for the less trusting. Albeit assembly source. something like that. The source distribution is also more portable, like to multiple versions of the OS, since the library names haven't been locked in yet -- Olaf and I found that OpenBSD is kind of a pain there, they rev the name of libc.so and apparently break old binaries. Maybe there is a compat option we didn't see (didn't look). We'll see about changes/progress here in future releases. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 12:46:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > Agreed, cross-compilation only needed for cm3 itself. PM3 used to distribute the derived .s files for each platform and installation required building cm3 from those. That way there was no need to deliver an executable cm3. It was all source. > > On 31 Jul 2009, at 12:35, Jay K wrote: > > > I actually think cross compilation support might have been very good in the first place. :) > In either case, yes, cross compilation support is good and easy now, if it wasn't earlier. > I only ever cross compile cm3 itself though, not the entire system. > Mainly what I did is some automation in pylib.py, which isn't all it should be, but again, enough for cm3. > It's arguably not much more than your scripts. > > > Oh, well, I also changed cm3.cfg to probe around for a reasonable cm3cg, so I could stop constantly overwriting the One /cm3/bin/cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. > Really we should ship to /cm3/bin/host/target/cm3cg probably. > > > Cross compiling the entire system will be useful for distribution purposes, but not in this release probably. > It will enable us to claim to build a distribution for some target, without actually having the target available..which is a little bit dishonest, granted, you couldn't have run the tests. > > > However it also allows cross building the entire system for slow targets, that you do have and will run the tests on, e.g. iphone, mips network router, my SGI machine, etc. > > > If you booted from other distributions...these package groups refer to something in them?? > > > - Jay > > ---------------------------------------- > Date: Fri, 31 Jul 2009 18:27:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hendrik at topoi.pooq.com Fri Jul 31 19:40:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 13:40:49 -0400 Subject: [M3devel] "how to build a distribution" In-Reply-To: References: Message-ID: <20090731174049.GA18464@topoi.pooq.com> On Fri, Jul 31, 2009 at 04:49:41PM +0000, Jay K wrote: > > On this matter there's actually more stuff worth mentioning. > > > Like, you always need various packages/libraries/tools that are often not in default minimal OS installs. > > > ODBC, X Windows, Postgres, bc, flex, bison, gcc, make, cvs, opengl, etc. > > > None of those are in the default Debian netinst for example. > And esp. the first few are not in many systems' default installations. >From the Debian binary point of view, the packages providing these should should be dependencies of the various libraries we generate that use them. Installing our library would then cause the other tools to be installed automatically. > > You don't need any of these, except for gcc basically, to use Modula-3. > But if you want to include all of "std", you need the C headers and/or librarie (often just libraries). Actually, Debian distinguishes several kind of packages: source packages -- the actual source code that people edit. binary packages -- what you need to use the software Usually executables and/or shared libraries doc -- often recommended or suggested by the binary packages and dev packages dev packages -- what you need to develop other software that uses the binary package. For C, this often consists of header files and kind of shim libraries that serve no purpose except to load the shared libraries. In our case, the source package for cm3 will probably have a build-dependency on one of the binary packages it generates. I wonder how C handles this. And how does this map onto the files Modula 3 uses and builds? -- hendrik From wagner at elegosoft.com Fri Jul 31 23:29:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 23:29:29 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: <20090731232929.r2v9z92sggkoogsc@mail.elegosoft.com> Quoting Tony Hosking : > Agreed, cross-compilation only needed for cm3 itself. PM3 used to > distribute the derived .s files for each platform and installation > required building cm3 from those. That way there was no need to > deliver an executable cm3. It was all source. I would like that to be possible with cm3, too. But we never built up the infrastructure to do it. Not for this release though ;-) Let's try to ge something delivered. Olaf > On 31 Jul 2009, at 12:35, Jay K wrote: > >> >> I actually think cross compilation support might have been very >> good in the first place. :) >> In either case, yes, cross compilation support is good and easy >> now, if it wasn't earlier. >> I only ever cross compile cm3 itself though, not the entire system. >> Mainly what I did is some automation in pylib.py, which isn't all >> it should be, but again, enough for cm3. >> It's arguably not much more than your scripts. >> >> >> Oh, well, I also changed cm3.cfg to probe around for a reasonable >> cm3cg, so I could stop constantly overwriting the One /cm3/bin/ >> cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. >> Really we should ship to /cm3/bin/host/target/cm3cg probably. >> >> >> Cross compiling the entire system will be useful for distribution >> purposes, but not in this release probably. >> It will enable us to claim to build a distribution for some target, >> without actually having the target available..which is a little >> bit dishonest, granted, you couldn't have run the tests. >> >> >> However it also allows cross building the entire system for slow >> targets, that you do have and will run the tests on, e.g. iphone, >> mips network router, my SGI machine, etc. >> >> >> If you booted from other distributions...these package groups refer >> to something in them?? >> >> >> - Jay >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 18:27:47 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> I meant getting the first instance of cm3 5.1 run on a certain platform. >>> And there was of course a first platform. We used the SRC compiler, >>> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >>> platforms. Later we used cross-compilation almost exclusively. >>> >>> I assume that cross-compilation support has improved dramatically >>> with all your changes. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> What does it mean to boot the compiler? >>>> >>>> >>>> I build the compiler from nothing but the compiler itself, >>>> and config files, and C compiler and linker, cvs >>>> to get all the source. >>>> That's not nothing, but it about the smallest start you can have, >>>> unless you rewrite the compiler in C, then you can start without >>>> the Modula-3 compiler. But at certain points in time this >>>> would not work, due to m3core and/or libm3 problems. >>>> It does work today. >>>> >>>> >>>> Is that booting? >>>> >>>> >>>> In future I'd like to dynamically link cm3, so I'd start with >>>> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" >>>> dependencies. Many other systems do dynamically link to this extent >>>> and we can to. >>>> >>>> >>>> I'm not just being obnoxious. >>>> Really, what does it mean? >>>> >>>> >>>> Should we just ship std and that's it? >>>> And even drop the name from it? >>>> cm3-PPC_LINUX-5.8.2.tar.gz ? >>>> >>>> >>>> (No need to say "POSIX", it is redundant). >>>> Just one download per platform? >>>> Not a big matrix of packages to test? >>>> >>>> >>>> Or do we look too fat in that packaging? :) >>>> >>>> >>>> Will too much stuff confuse users? >>>> >>>> >>>> Or mitigate the bulk with a little documentation/tutorial? >>>> >>>> >>>> Something like this: >>>> >>>> There are many libraries and packages. >>>> You do not need to worry about them. >>>> Here is hello world for a command line program: >>>> ... >>>> And for a gui program: >>>> ... >>>> And a minimal sample interoperating with C: >>>> ... >>>> And a minimal sample using Modula-3's RPC called "network objects": >>>> ... >>>> >>>> CM3 4.1 had some like this that were nice, presumably we have them. >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>>>> From: hendrik at topoi.pooq.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] package groups question >>>>> >>>>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>>>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> I don't care if future versions are not compilable with old cm3. But, >>>>>>>> vice versa, old versions should always be compilable with new cm3. >>>>>>>> >>>>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>>>> think that the average user should accept std as the install, while >>>>>>>> min is for power-users who know what they are doing. Does that jive >>>>>>>> with other people's expectations? >>>>>>> >>>>>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>>>>> list. Too much traffic for me to digest. >>>>>>> >>>>>>> I gather there's been a long discussion that `min' is not really >>>>>>> useful as it is not enough to build the system. When we started >>>>>>> the cm3 5 business many years ago with lots of uncompilable sources >>>>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>>>> >>>>>>> all - obvious meaning. most packages did not compile at all. >>>>>>> std - the set of packages shipped as compilable and usable with >>>>>>> every new release >>>>>>> core - a useful but small set of packages including everything to >>>>>>> bootstrap the compiler >>>>>>> boot - the minimal set to bootstrap the compiler >>>>>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>>>>> >>>>>>> As of today, std = all, and boot isn't used any more as far as >>>>>>> a I see. >>>>>> >>>>>> Is that becaouse no one ever boots the compiler any more? Or because >>>>>> there are better ways to do it? >>>>>> >>>>>> -- hendrik >>>>> >>>>> I guess I should mention that ebian is perfectly happy if one source >>>>> parckage (possibly the entire working cm3 system) generates multiple >>>>> binary packages. >>>>> >>>>> -- hendrik >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Wed Jul 1 11:03:19 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 01 Jul 2009 11:03:19 +0200 Subject: [M3devel] elego Servermaintenance 3.07.09 Message-ID: <20090701110319.l4ksn5e680ggg4kk@mail.elego.de> Liebe Kollegen, Liebe Elego-Kunden, In der Nacht von Freitag, dem 3.07 auf Samstag, den 4.07 werden wir um 22.00 CEST Uhr planmaessige Wartungsarbeiten an unseren Servern durchfuehren. Es kann zur kurzeitigen Unterbrechung mancher Dienste kommen. Voraussichtliche Dauer der Wartung: 120 Min. Wir bitten um Verst?ndnis. - die elego Admins On Friday, July 3 at 10 PM CEST, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 1 13:57:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Jul 2009 13:57:15 +0200 Subject: [M3devel] release build broken In-Reply-To: References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> Message-ID: <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> Quoting Jay : > > Ah, only the release build but not the latest, makes sense. > These weren't in m3core in older version. > Will fix. > After this release I can put it back. Jay, all the release builds are still broken in Tinderbox. Can you fix it your revert the offending commit? You also didn't answer if you're going to fix the path canonicalization function in quake. Can you do something there? Thanks, Olaf > > - Jay > > > > ---------------------------------------- >> Date: Tue, 30 Jun 2009 09:28:26 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release build broken >> >> The last commit to pkginfo.txt broke the Tinderbox release build: >> >> End of Log File >> "../src/Main.m3", line 4: unable to find interface (WinNT) >> "../src/Main.m3", line 5: unable to find interface (WinDef) >> compilation failed => not building program "mklib" >> Fatal Error: package build failed >> *** execution of cm3 -build >> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >> -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS >> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >> -DCM3_LAST_CHANGED=?2009-05-16? failed *** >> >> >> Please fix. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 1 17:45:05 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 15:45:05 +0000 Subject: [M3devel] release build broken In-Reply-To: <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> <20090701135715.6dtsbctz144c840g@mail.elegosoft.com> Message-ID: Release build should be ok now, for the next build. I'm not sure about the path stuff. What I was doing uses working code. - Jay ---------------------------------------- > Date: Wed, 1 Jul 2009 13:57:15 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release build broken > > Quoting Jay : > >> >> Ah, only the release build but not the latest, makes sense. >> These weren't in m3core in older version. >> Will fix. >> After this release I can put it back. > > Jay, > > all the release builds are still broken in Tinderbox. Can you fix it > your revert the offending commit? > > You also didn't answer if you're going to fix the path canonicalization > function in quake. Can you do something there? > > Thanks, > > Olaf > >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 30 Jun 2009 09:28:26 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] release build broken >>> >>> The last commit to pkginfo.txt broke the Tinderbox release build: >>> >>> End of Log File >>> "../src/Main.m3", line 4: unable to find interface (WinNT) >>> "../src/Main.m3", line 5: unable to find interface (WinDef) >>> compilation failed => not building program "mklib" >>> Fatal Error: package build failed >>> *** execution of cm3 -build >>> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >>> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >>> -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS >>> -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? >>> -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? >>> -DCM3_LAST_CHANGED=?2009-05-16? failed *** >>> >>> >>> Please fix. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 1 18:09:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 16:09:53 +0000 Subject: [M3devel] small builder bug when delete/rename files Message-ID: I believe there is a small builder bug for incremental builds when you move files: == package /home/jay/dev2/cm3/m3-sys/cm3 == +++ /tmp/tmpLXKqFE/compiler_with_previous/bin/cm3 -build -DROOT=/home/jay/dev2 /cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=20 09-05-16 @M3novm +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides Fatal Error: duplicate link info: M3Path.i3 *** execution of [, From jay.krell at cornell.edu Wed Jul 1 18:14:46 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Jul 2009 16:14:46 +0000 Subject: [M3devel] ChangeLog missing entries Message-ID: Many entries aren't interesting anyway, but the ChangeLog does miss stuff, at lease this one: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/intl/Attic/Makefile.in remove intl, libgomp, libssp, libmudflap that we don't build, use, or change http://modula3.elegosoft.com/cm3/ChangeLog-2009 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 1 18:54:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Jul 2009 18:54:03 +0200 Subject: [M3devel] ChangeLog missing entries In-Reply-To: References: Message-ID: <20090701185403.lgnqptijkg8g0w4w@mail.elegosoft.com> Quoting Jay : > Many entries aren't interesting anyway, but the ChangeLog does miss > stuff, at lease this one: > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/intl/Attic/Makefile.in > > remove intl, libgomp, libssp, libmudflap that we don't build, use, or > change > > > http://modula3.elegosoft.com/cm3/ChangeLog-2009 It's converted by a standard Perl script from the repository, IIRC. It's run by m3's crontab every on birch. Anybody there who'd like to have a look? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Jul 2 08:54:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Jul 2009 23:54:42 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Hi Modula-3ers (Tony?), I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot archive is broken on the web site... I remember there is some more or less hidden area where there are more archives, but I don't remember where? Mika From jay.krell at cornell.edu Thu Jul 2 09:08:58 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 07:08:58 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020654.n626sg3G082786@camembert.async.caltech.edu> References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: modula3.elegosoft.com/cm3/uploaded-archives But there aren't any I386_DARWIN. My I386_DARWIN seems to have a problem with its power supply, that's partly why nothing in releng. Can I suggest you try cross bootstrap? You know, so I can induct other people into my fun group? Here is how. Have some working machine already. Pretty much any platform. cd m3-sys/m3cc cm3 -DM3CC_TARGET=I386_DARWIN # That takes a little while. cd scripts/python cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. That config file delegates to the config files in the CVS tree. ./boot1.py I386_DARWIN This will produce something like ./cm3-boot-I386_DARWIN-1.tar.gz scp that file to your I386_DARWIN machine, then the rest is on the I386_DARWIN machine, extract it, cd into it, run make. That should give you cm3. Run it, make sure it runs ok, it should error about unable to find cm3.cfg. cvs checkout the whole tree. mkdir -p /usr/local/cm3/bin/config cp cm3 /usr/local/cm3/bin cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. You know have a working native bootstrap -- just cm3, cm3.cfg, the source tree. Complete the system with: ./do-cm3-std.py buildship - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Wed, 1 Jul 2009 23:54:42 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting I386_DARWIN? > > Hi Modula-3ers (Tony?), > > I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot > archive is broken on the web site... I remember there is some more or > less hidden area where there are more archives, but I don't remember > where? > > Mika From jay.krell at cornell.edu Thu Jul 2 09:41:56 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 07:41:56 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: Sorry, that was wrong: cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config should be: cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin I moved all the other files to config, but not cm3.cfg itself. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 07:08:58 +0000 > CC: mika at camembert.async.caltech.edu > Subject: Re: [M3devel] help booting I386_DARWIN? > > > modula3.elegosoft.com/cm3/uploaded-archives > > > But there aren't any I386_DARWIN. > My I386_DARWIN seems to have a problem with its power supply, that's partly why nothing in releng. > > > Can I suggest you try cross bootstrap? > You know, so I can induct other people into my fun group? > > > Here is how. > Have some working machine already. > Pretty much any platform. > > > cd m3-sys/m3cc > cm3 -DM3CC_TARGET=I386_DARWIN > # That takes a little while. > > > cd scripts/python > cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. > That config file delegates to the config files in the CVS tree. > > ./boot1.py I386_DARWIN > This will produce something like > ./cm3-boot-I386_DARWIN-1.tar.gz > > > scp that file to your I386_DARWIN machine, > then the rest is on the I386_DARWIN machine, > extract it, cd into it, run make. > That should give you cm3. > Run it, make sure it runs ok, it should error about unable to find cm3.cfg. > > > cvs checkout the whole tree. > mkdir -p /usr/local/cm3/bin/config > cp cm3 /usr/local/cm3/bin > cp m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/config or such. > > You know have a working native bootstrap -- just cm3, cm3.cfg, the source tree. > Complete the system with: > > > ./do-cm3-std.py buildship > > > > - Jay > > ---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Wed, 1 Jul 2009 23:54:42 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] help booting I386_DARWIN? >> >> Hi Modula-3ers (Tony?), >> >> I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot >> archive is broken on the web site... I remember there is some more or >> less hidden area where there are more archives, but I don't remember >> where? >> >> Mika From mika at async.caltech.edu Thu Jul 2 10:06:51 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 02 Jul 2009 01:06:51 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020806.n6286pFG085097@camembert.async.caltech.edu> Jay that's pretty nifty. The "cross" part of the build went fine (I figured out your config thing too), but it dies on the target: as PolyBasis.ms -o PolyBasis.ms.o as Main.is -o Main.is.o as WeakRef.ms -o WeakRef.ms.o as Word.ms -o Word.ms.o as Long.ms -o Long.ms.o gcc -g -fPIC -c hand.c -o hand.c.o gcc -g -fPIC -c dtoa.c -o dtoa.c.o gcc -g -fPIC -c libgcc.c -o libgcc.c.o gcc -g -fPIC -c RTLinkerC.c -o RTLinkerC.c.o gcc -g -fPIC -c RTOSmmap.c -o RTOSmmap.c.o gcc -g -fPIC -c RTSignalC.c -o RTSignalC.c.o RTSignalC.c: In function 'GetPC': RTSignalC.c:91: error: 'struct mcontext' has no member named 'sc' make: *** [RTSignalC.c.o] Error 1 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% uname -a Darwin unknown-00-17-f2-4c-66-5c.home 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% Am I perhaps using a hopeless version of OS X? Mika From jay.krell at cornell.edu Thu Jul 2 10:46:26 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 08:46:26 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020806.n6286pFG085097@camembert.async.caltech.edu> References: <200907020806.n6286pFG085097@camembert.async.caltech.edu> Message-ID: Just change the function GetPC to return 0 and move on, for now. We'll fix it correctly "later". I assume you are running 10.5? It worked for me on 10.4. There might be an #ifdef we can use to make it work on both. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jayk123 at hotmail.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 01:06:51 -0700 > From: mika at async.caltech.edu > > Jay that's pretty nifty. The "cross" part of the build went fine (I > figured out your config thing too), but it dies on the target: > > as PolyBasis.ms -o PolyBasis.ms.o > as Main.is -o Main.is.o > as WeakRef.ms -o WeakRef.ms.o > as Word.ms -o Word.ms.o > as Long.ms -o Long.ms.o > gcc -g -fPIC -c hand.c -o hand.c.o > gcc -g -fPIC -c dtoa.c -o dtoa.c.o > gcc -g -fPIC -c libgcc.c -o libgcc.c.o > gcc -g -fPIC -c RTLinkerC.c -o RTLinkerC.c.o > gcc -g -fPIC -c RTOSmmap.c -o RTOSmmap.c.o > gcc -g -fPIC -c RTSignalC.c -o RTSignalC.c.o > RTSignalC.c: In function 'GetPC': > RTSignalC.c:91: error: 'struct mcontext' has no member named 'sc' > make: *** [RTSignalC.c.o] Error 1 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% uname -a > Darwin unknown-00-17-f2-4c-66-5c.home 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > Am I perhaps using a hopeless version of OS X? > > Mika From mika at async.caltech.edu Thu Jul 2 10:55:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 02 Jul 2009 01:55:58 -0700 Subject: [M3devel] help booting I386_DARWIN? Message-ID: <200907020855.n628twBs086659@camembert.async.caltech.edu> Jay, all right, GetPC returns 0, and moving on.... [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make Makefile:3312: warning: overriding commands for target `UnixLink.c.o' Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' as M3Buf.ms -o M3Buf.ms.o M3Buf.ms:1610:operands given don't match any known 386 instruction M3Buf.ms:1618:operands given don't match any known 386 instruction make: *** [M3Buf.ms.o] Error 1 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms rep movsl movl %edx, -2184(%ebp) leal -2048(%ebp), %eax movl %eax, -2188(%ebp) movl $509, -2192(%ebp) movl -2184(%ebp), %edi movl -2188(%ebp), %esi movl -2192(%ebp), %ecx rep movsl [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% No this is what I have: [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S2167 [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% odd that it would work for you... hmm I wonder, maybe the Xcode needs updating? A little tricky in that case since I don't have console access and am not really a Mac guru. Mika From jay.krell at cornell.edu Thu Jul 2 10:59:02 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 08:59:02 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: Right. Look at I386_DARWIN. It probes for this. You have two choices. - difficult -- put a newline after each lock Their assembler does understand that I recall. - get a newer assembler; that's what I did I386_DARWIN will tell you what version I used, I don't know if older works. or maybe we could/should change cm3cg here. Heck, maybe there's a change in Apple's gcc to merge in. Or maybe, heck, just remove all occurences of lock. You only have one processor, right? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Thu, 2 Jul 2009 01:55:58 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting I386_DARWIN? > > Jay, all right, GetPC returns 0, and moving on.... > > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make > Makefile:3312: warning: overriding commands for target `UnixLink.c.o' > Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' > as M3Buf.ms -o M3Buf.ms.o > M3Buf.ms:1610:operands given don't match any known 386 instruction > M3Buf.ms:1618:operands given don't match any known 386 instruction > make: *** [M3Buf.ms.o] Error 1 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms > rep movsl > movl %edx, -2184(%ebp) > leal -2048(%ebp), %eax > movl %eax, -2188(%ebp) > movl $509, -2192(%ebp) > movl -2184(%ebp), %edi > movl -2188(%ebp), %esi > movl -2192(%ebp), %ecx > rep movsl > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > No this is what I have: > > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers > ProductName: Mac OS X > ProductVersion: 10.4.11 > BuildVersion: 8S2167 > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin8 > Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 > Thread model: posix > gcc version 4.0.1 (Apple Computer, Inc. build 5250) > [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% > > odd that it would work for you... hmm I wonder, maybe the Xcode needs > updating? > > A little tricky in that case since I don't have console access and > am not really a Mac guru. > > Mika From jay.krell at cornell.edu Thu Jul 2 11:00:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 09:00:22 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: er, I guess it is rep, not lock, and removing it will break it. Update your assembler or insert newlines.. Sorry. Probably running on 10.5 fixes it too... I tried configuring for older processors, 586, 486, 386 I /think/ none of that worked. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 08:59:02 +0000 > > > Right. Look at I386_DARWIN. > It probes for this. > You have two choices. > - difficult -- put a newline after each lock > Their assembler does understand that I recall. > > > - get a newer assembler; that's what I did > I386_DARWIN will tell you what version I used, I don't know if older works. > > > or maybe we could/should change cm3cg here. > Heck, maybe there's a change in Apple's gcc to merge in. > > > Or maybe, heck, just remove all occurences of lock. > You only have one processor, right? > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Thu, 2 Jul 2009 01:55:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] help booting I386_DARWIN? >> >> Jay, all right, GetPC returns 0, and moving on.... >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >> Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' >> as M3Buf.ms -o M3Buf.ms.o >> M3Buf.ms:1610:operands given don't match any known 386 instruction >> M3Buf.ms:1618:operands given don't match any known 386 instruction >> make: *** [M3Buf.ms.o] Error 1 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms >> rep movsl >> movl %edx, -2184(%ebp) >> leal -2048(%ebp), %eax >> movl %eax, -2188(%ebp) >> movl $509, -2192(%ebp) >> movl -2184(%ebp), %edi >> movl -2188(%ebp), %esi >> movl -2192(%ebp), %ecx >> rep movsl >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> No this is what I have: >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4.11 >> BuildVersion: 8S2167 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >> Using built-in specs. >> Target: i686-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 >> Thread model: posix >> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> odd that it would work for you... hmm I wonder, maybe the Xcode needs >> updating? >> >> A little tricky in that case since I don't have console access and >> am not really a Mac guru. >> >> Mika From jay.krell at cornell.edu Thu Jul 2 11:02:33 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 09:02:33 +0000 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020855.n628twBs086659@camembert.async.caltech.edu> References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: Btw, You don't need "console" access, like to a gui or "xcode". I, and I believe Olaf, used the stripped down "Darwin" that Apple released before it was selling x86 hardware. They don't have current 10.5 builds of that available but they do have 10.4. It works on some "normal" (non-Apple) hardware like some Dell laptops. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] help booting I386_DARWIN? > Date: Thu, 2 Jul 2009 09:00:22 +0000 > > > er, I guess it is rep, not lock, and removing it will break it. Update your assembler or insert newlines.. > Sorry. Probably running on 10.5 fixes it too... > I tried configuring for older processors, 586, 486, 386 I /think/ none of that worked. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] help booting I386_DARWIN? >> Date: Thu, 2 Jul 2009 08:59:02 +0000 >> >> >> Right. Look at I386_DARWIN. >> It probes for this. >> You have two choices. >> - difficult -- put a newline after each lock >> Their assembler does understand that I recall. >> >> >> - get a newer assembler; that's what I did >> I386_DARWIN will tell you what version I used, I don't know if older works. >> >> >> or maybe we could/should change cm3cg here. >> Heck, maybe there's a change in Apple's gcc to merge in. >> >> >> Or maybe, heck, just remove all occurences of lock. >> You only have one processor, right? >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> To: jay.krell at cornell.edu >>> Date: Thu, 2 Jul 2009 01:55:58 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] help booting I386_DARWIN? >>> >>> Jay, all right, GetPC returns 0, and moving on.... >>> >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >>> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >>> Makefile:687: warning: ignoring old commands for target `UnixLink.c.o' >>> as M3Buf.ms -o M3Buf.ms.o >>> M3Buf.ms:1610:operands given don't match any known 386 instruction >>> M3Buf.ms:1618:operands given don't match any known 386 instruction >>> make: *** [M3Buf.ms.o] Error 1 >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n 1610,1618p M3Buf.ms >>> rep movsl >>> movl %edx, -2184(%ebp) >>> leal -2048(%ebp), %eax >>> movl %eax, -2188(%ebp) >>> movl $509, -2192(%ebp) >>> movl -2184(%ebp), %edi >>> movl -2188(%ebp), %esi >>> movl -2192(%ebp), %ecx >>> rep movsl >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >>> >>> No this is what I have: >>> >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >>> ProductName: Mac OS X >>> ProductVersion: 10.4.11 >>> BuildVersion: 8S2167 >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >>> Using built-in specs. >>> Target: i686-apple-darwin8 >>> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 >>> Thread model: posix >>> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >>> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >>> >>> odd that it would work for you... hmm I wonder, maybe the Xcode needs >>> updating? >>> >>> A little tricky in that case since I don't have console access and >>> am not really a Mac guru. >>> >>> Mika From lists at darko.org Thu Jul 2 12:16:29 2009 From: lists at darko.org (Darko Volaric) Date: Thu, 2 Jul 2009 12:16:29 +0200 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: <200907020654.n626sg3G082786@camembert.async.caltech.edu> References: <200907020654.n626sg3G082786@camembert.async.caltech.edu> Message-ID: <107CE119-1777-4132-A24E-3C6075C625FD@darko.org> It's in Tony's private stash: ftp://ftp.cs.purdue.edu/pub/hosking/m3/ On 02/07/2009, at 8:54 AM, Mika Nystrom wrote: > Hi Modula-3ers (Tony?), > > I'm finally ready to try CM3 on I386_DARWIN. But the link to the boot > archive is broken on the web site... I remember there is some more or > less hidden area where there are more archives, but I don't remember > where? > > Mika From wagner at elegosoft.com Thu Jul 2 12:35:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Jul 2009 12:35:33 +0200 Subject: [M3devel] stepping on your toes In-Reply-To: References: <20090629093610.blv4zraf4ocowk8w@mail.elegosoft.com> <35F93BA7-A05C-4633-89F0-211C5C0256EA@hotmail.com> <20090629110826.mkugfxs884c0owcc@mail.elegosoft.com> <20090701184824.6oeqk8cdbggw8owc@mail.elegosoft.com> <20090702082756.e5lkauyzfo44000k@mail.elegosoft.com> Message-ID: <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> Quoting Jay : > Olaf, the ws packages contain source and unshipped outputs, right? > What do you think is the point of these archives vs. binary-only and > source-only archives? I have ideas but I don't want to lead you. The idea was to reduce the number of packages, as M3 does not really support the separation of source and derived files for binary packages. So why not just enrich the source with just the products needed for shipping? This is sort of the smallest supported _M3_-binary package. Both system-dependent source and binary packages can be based on the same collection of ws packages. Traditionally CM3 offered only sources packages except for the minimal installation archive. There were lots of problems with o people understanding how to compile the source and o actual compilation errors due to miscellaneous causes People wanted something that is easy to install (without using lots of complex scripts). So I extended the standard cm3 builder so it can be used for such an installation. These are exactly the ws archives. M3 source and derived files which are needed for shipping an M3 package, but not more. I found that rather nice. >> core vs. min vs. boot > > Yeah I was equating min with boot. > Still, as to what is "minimal" vs. "useful", not clear. For example, > "minimal" can be reduced by not allowing for static linking. The > .sa files add a lot of size. But that is slightly less useful, so > someone who wants to make standalone programs. > And min still varies in definition depending on one's prediction of > the future. > > Even then there are multiple definitions here: > boot for the current matching release > or boot for the next release? > > If it is for the matching release, no problem predicting the future, > it is just the assembly code for cm3, and no provision for creating > a package store with any contents, until user also gets source and > builds it. I have in mind the old 3.6 release form, though we can't > quite emulate it, now that the builder is in M3 and not C. > > I'd like to look into this cross building of boot/assembly releases, > though first some other things.. The whole cross-compilation topic is not really relevant for a release IMO. There are very few people who actually want to do such things ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Jul 2 15:42:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 09:42:31 -0400 Subject: [M3devel] help booting I386_DARWIN? In-Reply-To: References: <200907020855.n628twBs086659@camembert.async.caltech.edu> Message-ID: <073CA2E9-4E98-449E-B725-E478A0F8D20D@cs.purdue.edu> Best to upgrade xcode. On 2 Jul 2009, at 04:59, Jay wrote: > > Right. Look at I386_DARWIN. > It probes for this. > You have two choices. > - difficult -- put a newline after each lock > Their assembler does understand that I recall. > > > - get a newer assembler; that's what I did > I386_DARWIN will tell you what version I used, I don't know if > older works. > > > or maybe we could/should change cm3cg here. > Heck, maybe there's a change in Apple's gcc to merge in. > > > Or maybe, heck, just remove all occurences of lock. > You only have one processor, right? > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Thu, 2 Jul 2009 01:55:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] help booting I386_DARWIN? >> >> Jay, all right, GetPC returns 0, and moving on.... >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% make >> Makefile:3312: warning: overriding commands for target `UnixLink.c.o' >> Makefile:687: warning: ignoring old commands for target >> `UnixLink.c.o' >> as M3Buf.ms -o M3Buf.ms.o >> M3Buf.ms:1610:operands given don't match any known 386 instruction >> M3Buf.ms:1618:operands given don't match any known 386 instruction >> make: *** [M3Buf.ms.o] Error 1 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sed -n >> 1610,1618p M3Buf.ms >> rep movsl >> movl %edx, -2184(%ebp) >> leal -2048(%ebp), %eax >> movl %eax, -2188(%ebp) >> movl $509, -2192(%ebp) >> movl -2184(%ebp), %edi >> movl -2188(%ebp), %esi >> movl -2192(%ebp), %ecx >> rep movsl >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> No this is what I have: >> >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4.11 >> BuildVersion: 8S2167 >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% gcc -v >> Using built-in specs. >> Target: i686-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure >> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man >> --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/ >> ^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- >> build=powerpc-apple-darwin8 --with-arch=pentium-m --with- >> tune=prescott --program-prefix= --host=i686-apple-darwin8 -- >> target=i686-apple-darwin8 >> Thread model: posix >> gcc version 4.0.1 (Apple Computer, Inc. build 5250) >> [unknown-00-17-f2-4c-66-5c:~/cm3-boot-I386_DARWIN-1] mika% >> >> odd that it would work for you... hmm I wonder, maybe the Xcode needs >> updating? >> >> A little tricky in that case since I don't have console access and >> am not really a Mac guru. >> >> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 2 17:08:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 2 Jul 2009 11:08:17 -0400 Subject: [M3devel] stepping on your toes In-Reply-To: <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> References: <20090629093610.blv4zraf4ocowk8w@mail.elegosoft.com> <35F93BA7-A05C-4633-89F0-211C5C0256EA@hotmail.com> <20090629110826.mkugfxs884c0owcc@mail.elegosoft.com> <20090701184824.6oeqk8cdbggw8owc@mail.elegosoft.com> <20090702082756.e5lkauyzfo44000k@mail.elegosoft.com> <20090702123533.8zdemv9pm4okoksc@mail.elegosoft.com> Message-ID: <20090702150816.GC21089@topoi.pooq.com> On Thu, Jul 02, 2009 at 12:35:33PM +0200, Olaf Wagner wrote: > Quoting Jay : > > >Olaf, the ws packages contain source and unshipped outputs, right? > >What do you think is the point of these archives vs. binary-only and > > source-only archives? I have ideas but I don't want to lead you. > > The idea was to reduce the number of packages, as M3 does not > really support the separation of source and derived files for binary > packages. So why not just enrich the source with just the products > needed for shipping? This is sort of the smallest supported _M3_-binary > package. > > Both system-dependent source and binary packages can be based on the > same collection of ws packages. > > Traditionally CM3 offered only sources packages except for the minimal > installation archive. There were lots of problems with > > o people understanding how to compile the source and > o actual compilation errors due to miscellaneous causes > > People wanted something that is easy to install (without using lots > of complex scripts). So I extended the standard cm3 builder so it can > be used for such an installation. Just a point of interest. Debian has a number of apparently proprietary packages -- such as the one for nvidia drivers. What they do is, during installation, connect to the nvidia web site to download the driver, then install the result of downloading. So a significane amount of very package-dependent work can be done during installation -- such as compiling. It may not be in the spirit of binary packages, but can be made to work automatically. What this doesn't do is enable multiple binary packages to be built from a single source -- which Debian also does frmo time to time, but at headquarters, not in apt or aptitude. > > These are exactly the ws archives. M3 source and derived files which > are needed for shipping an M3 package, but not more. I found that > rather nice. > > > >>core vs. min vs. boot > > > >Yeah I was equating min with boot. > >Still, as to what is "minimal" vs. "useful", not clear. For example, > > "minimal" can be reduced by not allowing for static linking. The > >.sa files add a lot of size. But that is slightly less useful, so > >someone who wants to make standalone programs. > >And min still varies in definition depending on one's prediction of > >the future. > > > >Even then there are multiple definitions here: > > boot for the current matching release > > or boot for the next release? > > > >If it is for the matching release, no problem predicting the future, > > it is just the assembly code for cm3, and no provision for creating > > a package store with any contents, until user also gets source and > >builds it. I have in mind the old 3.6 release form, though we can't > >quite emulate it, now that the builder is in M3 and not C. > > > >I'd like to look into this cross building of boot/assembly releases, > > though first some other things.. > > The whole cross-compilation topic is not really relevant for a > release IMO. There are very few people who actually want to do > such things ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hosking at cs.purdue.edu Thu Jul 2 17:43:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:43:35 -0400 Subject: [M3devel] Error in building cm3 Message-ID: I've just updated m3-sys/cm3 and now get the following error when building. What gives? --- building in SOLgnu --- ignoring ../src/m3overrides "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: undefined variable: ROOT --procedure-- -line- -file--- include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile 5 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/ SOLgnu/m3make.args Fatal Error: package build failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 17:49:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Message-ID: Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. From hosking at cs.purdue.edu Thu Jul 2 17:51:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:51:30 -0400 Subject: [M3devel] UnixLink.c Message-ID: It seems fundamentally broken to me that m3-sys/cm3 should be doing all this copying of UnixLink just so some previous m3core can be linked to. Surely, when bootstrapping you need to compile a *new* m3core against which cm3 wil link. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 17:54:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 11:54:51 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: If I define ROOT then I get the following error. I think this all needs reverting! --- building in SOLgnu --- ignoring ../src/m3overrides "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ Common/UnixLink.c" to "./UnixLink.c": errno=2 --procedure-- -line- -file--- cp_if -- include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/ SOLgnu/m3make.args Fatal Error: package build failed n On 2 Jul 2009, at 11:49, Tony Hosking wrote: > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 18:19:03 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:19:03 +0000 Subject: [M3devel] UnixLink.c In-Reply-To: References: Message-ID: > Surely, when bootstrapping you need to > compile a *new* m3core against which cm3 wil link. Nope. As long as we have those "release" tinderbox builds that build from 5.4 m3core... Remove that requirement and I'd gladly clean this up. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:51:30 -0400 > Subject: [M3devel] UnixLink.c > > It seems fundamentally broken to me that m3-sys/cm3 should be doing all this copying of UnixLink just so some previous m3core can be linked to. Surely, when bootstrapping you need to compile a *new* m3core against which cm3 wil link. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > From jay.krell at cornell.edu Thu Jul 2 18:19:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:19:49 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: > Seems broken to me to depend on > the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > From jay.krell at cornell.edu Thu Jul 2 18:21:07 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:21:07 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Are you up to date in m3-libs/m3core? Lots of builds have succeeded with this.. It isn't great, but that requirement to build from previous 5.4 release.. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Thu, 2 Jul 2009 11:54:51 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > If I define ROOT then I get the following error. I think this all needs reverting! > > --- building in SOLgnu --- > > ignoring ../src/m3overrides > > "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/Common/UnixLink.c" to "./UnixLink.c": errno=2 > > --procedure-- -line- -file--- > cp_if -- > include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile > 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > > Fatal Error: package build failed > n > > On 2 Jul 2009, at 11:49, Tony Hosking wrote: > > Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. > > From hosking at cs.purdue.edu Thu Jul 2 18:40:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 12:40:18 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: I'm not talking about m3overrides. That is a arguably a special- purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: > >> Seems broken to me to depend on >> the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 18:42:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 12:42:52 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Whether or not I am up-to-date I dislike the whole ROOT dependence for standard builds! On 2 Jul 2009, at 12:21, Jay wrote: > > Are you up to date in m3-libs/m3core? > Lots of builds have succeeded with this.. > It isn't great, but that requirement to build from previous 5.4 > release.. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 2 Jul 2009 11:54:51 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ROOT >> >> If I define ROOT then I get the following error. I think this all >> needs reverting! >> >> --- building in SOLgnu --- >> >> ignoring ../src/m3overrides >> >> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: >> quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ >> Common/UnixLink.c" to "./UnixLink.c": errno=2 >> >> --procedure-- -line- -file--- >> cp_if -- >> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >> m3makefile >> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >> >> Fatal Error: package build failed >> n >> >> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as >> it sets that structure in stone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 18:55:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 16:55:16 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: As long as there is a need to work with older m3core, there will be hacks.. This stuff provides a significant value. Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > From jay.krell at cornell.edu Thu Jul 2 19:13:05 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 17:13:05 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: Btw, I think setting an environment variable that points to the root of the source tree is a pretty small cost to pay, for almost anything. ROOT is a bit generic I realize. It is worse to be copying files around, I admit, and I'm doing that too. Another option is to copy /and/ commit the files, perhaps to sysutils, since we don't have to work with an old sysutils. This is the same sort of problem, you'll recall, that plagued making waitpid users not sleep() on pthreads platforms. There are still small hacks in place for that -- pretty small now, like, assuming we are on pthreads and not sleeping, to the detriment of user threads implementations. CM3_ROOT should work, but that might depend on your config file. I am strongly tempted to have cm3 poke around in the CVS directories and figure it out itself, as so many builds are run with .sh code that does roughly that. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ROOT > Date: Thu, 2 Jul 2009 16:55:16 +0000 > > > As long as there is a need to work with older m3core, there will be hacks.. > This stuff provides a significant value. > Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. > > > With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. > > As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 12:40:18 -0400 >> >> I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 2 Jul 2009, at 12:19, Jay wrote: >> >> >> Seems broken to me to depend on >> the source directory structure >> >> Like m3overrides? But yes, I agree. >> m3overrides seems broken too. >> >> - Jay >> >> >> >> >> >> >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> >> From jay.krell at cornell.edu Thu Jul 2 19:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 17:14:43 +0000 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: [truncated..] ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ROOT > Date: Thu, 2 Jul 2009 17:13:05 +0000 > > > Btw, I think setting an environment variable that points to the root of the source tree is a pretty small cost to pay, for almost anything. > ROOT is a bit generic I realize. > > > It is worse to be copying files around, I admit, and I'm doing that too. > Another option is to copy /and/ commit the files, perhaps to sysutils, since we don't have to work with an old sysutils. This is the same sort of problem, you'll recall, that plagued making waitpid users not sleep() on pthreads platforms. There are still small hacks in place for that -- pretty small now, like, assuming we are on pthreads and not sleeping, to the detriment of user threads implementations. > > > CM3_ROOT should work, but that might depend on your config file. > > I am strongly tempted to have cm3 poke around in the CVS directories and figure it out itself, as so many builds are run with .sh code that does roughly that. > > - Jay > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 16:55:16 +0000 >> >> >> As long as there is a need to work with older m3core, there will be hacks.. >> This stuff provides a significant value. >> Before, the runpaths recorded would be a directory per dependent shared object -- the directory in the package store. And the runpaths were not machine portable -- if you install to a different location, which is debatable, maybe everyone should be stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >> >> >> With the hard links, people don't have to set LD_LIBRARY_PATH and everyone can pick their own install location. >> >> As well the temporary staging location for a distribution is not recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but /tmp/something. >> >> >> - Jay >> >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>> >>> I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 2 Jul 2009, at 12:19, Jay wrote: >>> >>> >>> Seems broken to me to depend on >>> the source directory structure >>> >>> Like m3overrides? But yes, I agree. >>> m3overrides seems broken too. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>> Subject: [M3devel] ROOT >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as it >>> sets that structure in stone. >>> >>> >>> From hosking at cs.purdue.edu Thu Jul 2 19:47:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:47:44 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> On 2 Jul 2009, at 12:55, Jay wrote: > As long as there is a need to work with older m3core, there will be > hacks.. But why would you compile a new cm3 with an old m3core? > This stuff provides a significant value. > Before, the runpaths recorded would be a directory per dependent > shared object -- the directory in the package store. And the > runpaths were not machine portable -- if you install to a different > location, which is debatable, maybe everyone should be stuck with / > usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > With the hard links, people don't have to set LD_LIBRARY_PATH and > everyone can pick their own install location. Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? > As well the temporary staging location for a distribution is not > recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, but / > tmp/something. I'd really like to hear opinions on this from others. > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 12:40:18 -0400 >> >> I'm not talking about m3overrides. That is a arguably a special- >> purpose hack. We shouldn't layer a hack into the *normal* build >> process. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 2 Jul 2009, at 12:19, Jay wrote: >> >> >> Seems broken to me to depend on >> the source directory structure >> >> Like m3overrides? But yes, I agree. >> m3overrides seems broken too. >> >> - Jay >> >> >> >> >> >> >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Thu, 2 Jul 2009 11:49:34 -0400 >> Subject: [M3devel] ROOT >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as it >> sets that structure in stone. >> >> >> From hosking at cs.purdue.edu Thu Jul 2 19:51:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:51:00 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <314CD2AE-A9E0-4D23-BDEC-DFD776DB8FB7@cs.purdue.edu> On 2 Jul 2009, at 13:13, Jay wrote: > Btw, I think setting an environment variable that points to the root > of the source tree is a pretty small cost to pay, for almost anything. But, again, this hardcodes the source tree structure into the configuration files, which I really hate. > ROOT is a bit generic I realize. > > > It is worse to be copying files around, I admit, and I'm doing that > too. Right. > Another option is to copy /and/ commit the files, perhaps to > sysutils, since we don't have to work with an old sysutils. This is > the same sort of problem, you'll recall, that plagued making waitpid > users not sleep() on pthreads platforms. There are still small hacks > in place for that -- pretty small now, like, assuming we are on > pthreads and not sleeping, to the detriment of user threads > implementations. > > > CM3_ROOT should work, but that might depend on your config file. > > I am strongly tempted to have cm3 poke around in the CVS directories > and figure it out itself, as so many builds are run with .sh code > that does roughly that. Perhaps you can step back and provide a high-level rationale for what is needed, and how best to accomplish it. I've lost the big picture here. > > - Jay > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 16:55:16 +0000 >> >> >> As long as there is a need to work with older m3core, there will be >> hacks.. >> This stuff provides a significant value. >> Before, the runpaths recorded would be a directory per dependent >> shared object -- the directory in the package store. And the >> runpaths were not machine portable -- if you install to a different >> location, which is debatable, maybe everyone should be stuck with / >> usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >> >> >> With the hard links, people don't have to set LD_LIBRARY_PATH and >> everyone can pick their own install location. >> >> As well the temporary staging location for a distribution is not >> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >> but /tmp/something. >> >> >> - Jay >> >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>> >>> I'm not talking about m3overrides. That is a arguably a special- >>> purpose hack. We shouldn't layer a hack into the *normal* build >>> process. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 2 Jul 2009, at 12:19, Jay wrote: >>> >>> >>> Seems broken to me to depend on >>> the source directory structure >>> >>> Like m3overrides? But yes, I agree. >>> m3overrides seems broken too. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>> Subject: [M3devel] ROOT >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as it >>> sets that structure in stone. >>> >>> >>> From hosking at cs.purdue.edu Thu Jul 2 19:51:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:51:36 -0400 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> PS I don't see the truncated e-mails when I get them -- must be something broken on your end. On 2 Jul 2009, at 13:14, Jay wrote: > > [truncated..] > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] ROOT >> Date: Thu, 2 Jul 2009 17:13:05 +0000 >> >> >> Btw, I think setting an environment variable that points to the >> root of the source tree is a pretty small cost to pay, for almost >> anything. >> ROOT is a bit generic I realize. >> >> >> It is worse to be copying files around, I admit, and I'm doing that >> too. >> Another option is to copy /and/ commit the files, perhaps to >> sysutils, since we don't have to work with an old sysutils. This is >> the same sort of problem, you'll recall, that plagued making >> waitpid users not sleep() on pthreads platforms. There are still >> small hacks in place for that -- pretty small now, like, assuming >> we are on pthreads and not sleeping, to the detriment of user >> threads implementations. >> >> >> CM3_ROOT should work, but that might depend on your config file. >> >> I am strongly tempted to have cm3 poke around in the CVS >> directories and figure it out itself, as so many builds are run >> with .sh code that does roughly that. >> >> - Jay >> >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 16:55:16 +0000 >>> >>> >>> As long as there is a need to work with older m3core, there will >>> be hacks.. >>> This stuff provides a significant value. >>> Before, the runpaths recorded would be a directory per dependent >>> shared object -- the directory in the package store. And the >>> runpaths were not machine portable -- if you install to a >>> different location, which is debatable, maybe everyone should be >>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >>> >>> >>> With the hard links, people don't have to set LD_LIBRARY_PATH and >>> everyone can pick their own install location. >>> >>> As well the temporary staging location for a distribution is not >>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >>> but /tmp/something. >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>>> CC: m3devel at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: [M3devel] ROOT >>>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>>> >>>> I'm not talking about m3overrides. That is a arguably a special- >>>> purpose hack. We shouldn't layer a hack into the *normal* build >>>> process. >>>> >>>> >>>> Antony Hosking | Associate Professor | Computer Science | Purdue >>>> University >>>> 305 N. University Street | West Lafayette | IN 47907 | USA >>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>>> >>>> >>>> >>>> >>>> On 2 Jul 2009, at 12:19, Jay wrote: >>>> >>>> >>>> Seems broken to me to depend on >>>> the source directory structure >>>> >>>> Like m3overrides? But yes, I agree. >>>> m3overrides seems broken too. >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: m3devel at elegosoft.com >>>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>>> Subject: [M3devel] ROOT >>>> >>>> Where did variable ROOT come from? Do I really need to define it? >>>> Seems broken to me to depend on the source directory structure as >>>> it >>>> sets that structure in stone. >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 19:53:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 13:53:07 -0400 Subject: [M3devel] ROOT In-Reply-To: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> Message-ID: <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> That sounds plausible. Is there anything in the current setup that depends on the .so files being in pkg instead of lib? On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > How about we put .so files only in lib and not in pkg? Or symlink > from pkg to lib instead of how it used to be the other way around? > Those would also fix all this. > > - Jay (phone) > > On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> >> Are you up to date in m3-libs/m3core? >> Lots of builds have succeeded with this.. >> It isn't great, but that requirement to build from previous 5.4 >> release.. >> >> - Jay >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 2 Jul 2009 11:54:51 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] ROOT >>> >>> If I define ROOT then I get the following error. I think this all >>> needs reverting! >>> >>> --- building in SOLgnu --- >>> >>> ignoring ../src/m3overrides >>> >>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line >>> 12: quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/ >>> unix/Common/UnixLink.c" to "./UnixLink.c": errno=2 >>> >>> --procedure-- -line- -file--- >>> cp_if -- >>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >>> m3makefile >>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >>> >>> Fatal Error: package build failed >>> n >>> >>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >>> >>> Where did variable ROOT come from? Do I really need to define it? >>> Seems broken to me to depend on the source directory structure as >>> it sets that structure in stone. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 2 20:04:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Jul 2009 20:04:36 +0200 Subject: [M3devel] ROOT In-Reply-To: <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> Message-ID: <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Quoting Tony Hosking : > That sounds plausible. Is there anything in the current setup that > depends on the .so files being in pkg instead of lib? I don't think so offhand. But I must admit that I've lost the overview in this area, too :-/ Olaf > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > >> How about we put .so files only in lib and not in pkg? Or symlink >> from pkg to lib instead of how it used to be the other way around? >> Those would also fix all this. >> >> - Jay (phone) >> >> On Jul 2, 2009, at 9:21 AM, Jay wrote: >> >>> >>> Are you up to date in m3-libs/m3core? >>> Lots of builds have succeeded with this.. >>> It isn't great, but that requirement to build from previous 5.4 release.. >>> >>> - Jay >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] ROOT >>>> >>>> If I define ROOT then I get the following error. I think this all >>>> needs reverting! >>>> >>>> --- building in SOLgnu --- >>>> >>>> ignoring ../src/m3overrides >>>> >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line >>>> 12: quake runtime error: unable to copy >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to >>>> "./UnixLink.c": errno=2 >>>> >>>> --procedure-- -line- -file--- >>>> cp_if -- >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >>>> >>>> Fatal Error: package build failed >>>> n >>>> >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >>>> >>>> Where did variable ROOT come from? Do I really need to define it? >>>> Seems broken to me to depend on the source directory structure >>>> as it sets that structure in stone. >>>> >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 2 20:09:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 11:09:40 -0700 Subject: [M3devel] ROOT In-Reply-To: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> Message-ID: <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> The ones sent directly to people aren't truncated, only when they go through m3devel. - Jay (phone) On Jul 2, 2009, at 10:51 AM, Tony Hosking wrote: > PS I don't see the truncated e-mails when I get them -- must be > something broken on your end. > > On 2 Jul 2009, at 13:14, Jay wrote: > >> >> [truncated..] >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] ROOT >>> Date: Thu, 2 Jul 2009 17:13:05 +0000 >>> >>> >>> Btw, I think setting an environment variable that points to the >>> root of the source tree is a pretty small cost to pay, for almost >>> anything. >>> ROOT is a bit generic I realize. >>> >>> >>> It is worse to be copying files around, I admit, and I'm doing >>> that too. >>> Another option is to copy /and/ commit the files, perhaps to >>> sysutils, since we don't have to work with an old sysutils. This >>> is the same sort of problem, you'll recall, that plagued making >>> waitpid users not sleep() on pthreads platforms. There are still >>> small hacks in place for that -- pretty small now, like, assuming >>> we are on pthreads and not sleeping, to the detriment of user >>> threads implementations. >>> >>> >>> CM3_ROOT should work, but that might depend on your config file. >>> >>> I am strongly tempted to have cm3 poke around in the CVS >>> directories and figure it out itself, as so many builds are run >>> with .sh code that does roughly that. >>> >>> - Jay >>> >>> >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] ROOT >>>> Date: Thu, 2 Jul 2009 16:55:16 +0000 >>>> >>>> >>>> As long as there is a need to work with older m3core, there will >>>> be hacks.. >>>> This stuff provides a significant value. >>>> Before, the runpaths recorded would be a directory per dependent >>>> shared object -- the directory in the package store. And the >>>> runpaths were not machine portable -- if you install to a >>>> different location, which is debatable, maybe everyone should be >>>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH. >>>> >>>> >>>> With the hard links, people don't have to set LD_LIBRARY_PATH and >>>> everyone can pick their own install location. >>>> >>>> As well the temporary staging location for a distribution is not >>>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3, >>>> but /tmp/something. >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ________________________________ >>>>> CC: m3devel at elegosoft.com >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Subject: Re: [M3devel] ROOT >>>>> Date: Thu, 2 Jul 2009 12:40:18 -0400 >>>>> >>>>> I'm not talking about m3overrides. That is a arguably a special- >>>>> purpose hack. We shouldn't layer a hack into the *normal* build >>>>> process. >>>>> >>>>> >>>>> Antony Hosking | Associate Professor | Computer Science | Purdue >>>>> University >>>>> 305 N. University Street | West Lafayette | IN 47907 | USA >>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>>>> >>>>> >>>>> >>>>> >>>>> On 2 Jul 2009, at 12:19, Jay wrote: >>>>> >>>>> >>>>> Seems broken to me to depend on >>>>> the source directory structure >>>>> >>>>> Like m3overrides? But yes, I agree. >>>>> m3overrides seems broken too. >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Thu, 2 Jul 2009 11:49:34 -0400 >>>>> Subject: [M3devel] ROOT >>>>> >>>>> Where did variable ROOT come from? Do I really need to define it? >>>>> Seems broken to me to depend on the source directory structure >>>>> as it >>>>> sets that structure in stone. >>>>> >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Thu Jul 2 20:31:45 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 14:31:45 -0400 Subject: [M3devel] ROOT In-Reply-To: <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> Message-ID: <4A4CC4CE.1E75.00D7.1@scires.com> I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Thu Jul 2 20:41:27 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:41:27 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: Before I explain, more options: copy and commit the source to cm3 is viable heck, use a relative instead of absolute from ROOT go back to the old way (I'll explain) There is also the option to relink or "fixup" upon ship and/or install. Some platforms have a "fixup" utility for exactly "these reasons". MacOS X has one. The question is: How does program foo find libbar.so? At runtime. How does libbar.so find libfoo.so? There are a bewildering array of choices. They are combinable. It varies somewhat from platform by platform, but not much really. The main options are: 1: A full path written into program foo or libbar pointing to e.g. /usr/lib/libfoo.so. Actually this is usually separate libfoo.so and a list of directories that apply to all .so files. There isn't generally a matching up of directory to file, I think, but a "search path" aka "run path". 2: A relative path written into program foo or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. Again, the directories are split from the files. MacOS X doesn't have $ORIGIN by that name, but it has three similar things, like @executable_path. @executable_path goes way back and is presumably relative to the primary main executable. There are two other similar options. One is new in 10.5. Presumably one is relative to the reference. And maybe one is some concatenation of all directories anything found in so far? I don't know. The documenation was not clear to me. NetBSD prior to 5.0 doesn't have $ORIGIN. NT searches $PATH always. We put the .dlls in bin. Cygwin same. Approximately all other systems seem to support about the same $ORIGIN feature: OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?) The MacOS X feature is close enough to lump in. 3: Search $LD_LIBRARY_PATH or similar. This has a few different names. LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. Now, our historical implementation was - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, a path for every dependency The file formats are generally such that there are leaf file names separate from an array of directories to look in. A "normal" non-Modula-3 program would generally I assume have a prety small such array of directories. A "normal" Modula-3 program would have a fairly large array. As well, doing builds for distribution would often leave you with /tmp/cm3 which is a possible security problem. This definitely did occur. Now, again, there are many options, and they can be combined. Portability is perhaps a concern, but perhaps not so much, given today's landscape. Now, if we are to use relative paths, well, my understanding is that the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib, and not /usr/local/cm3/pkg/foo/linux etc. This way, files in lib and bin can point to $ORIGIN/../lib. Now, keep in mind, that unshipped binaries sometimes people like to work, as well, perhaps also programs (not shared libraies, as far as I know) buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. I know cm3 sits in there, though that copy isn't used. I make no account for binaries buried in the package store. I do make some account for unshipped binaries. By default the run paths we are recording in current config files are $ORIGIN/../lib:/usr/local/cm3/lib Not a bunch of paths into pkg, just two entries. The "security" issue still is present by default. But the run path is "prettier" and probably more efficient. When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3). This is controled by an environment variable, which I set in Olaf's scripts, but oops I think I set it too late. I'll fix that very very soon. To recap: - full paths - relative paths from $ORIGIN - LD_LIBRARY_PATH They each have advantages and disadvantages. $ORIGIN provides for a "movable" install. I can install to /usr/local/cm3, you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH. However if I want to move just some of the files, not the whole binary tree together, then $ORIGIN breaks down. If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do. You are left with full paths or LD_LIBRARY_PATH. Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such. Look on birch for example, it is /usr/local/cm3/lib. That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there. This demonstrated another problem in this area! $ORIGIN keeps things more tightly together, which you often want, sometimes might not not. LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not. I figure tightly point is the more common, but imagine if you just want to replace one file. Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install this way.) So, here now I'm rambling. I've laid out the options and /some/ of the disadvantages/advantages. There is no perfect solution, and the various solutions are combinable. I find combining them though, I start to get confused. Because you end up in a "probing" situation and you start wondering which supercedes which, and you just hope there aren't any "duplicates" so that the probe order is mostly moot (assuming there remain no duplicates). Somewhat clear? You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and investigate the various options and their effects. Solaris has a very nice and verbose ldd form. Now, the files in pkg. I consider it somewhat philosophically significant that "everything is in pkg". There is a well structured "repository" not a randomly organized bunch of files. I think. Maybe this is just a suggestion? You know, if they are hardlinks and we don't really use the ones in pkg, is there a point? Or, on the other hand, is the philosophy a big deal and we should go back to lib symlinking to pkg to appease the philosophy? "ship/install" certainly "likes" to put things in pkg. I don't think the option of using lib and not pkg is doable without builder changes. But that is doable. A few other folks here did pipe up some on this in the recent past and I think there was kinda sorta consensus that the old ways were not great (particularly 1) the big runpath 2) the runpath into /tmp) and the new ways maybe better, but I admit there was no clear consensus. I acted somewhat unilaterally. You know, I'm impatient and arrogant so... and Tinderbox is there to cause some restraint. There was definitely pushback on wanting unshipped binaries to keep working, which they largely do as a result of the discussion/pushback. As well, any unshipped binaries that we know we use in the build, like PklFonts, stubgen, m3bundle, we build standalone, to evade/avoid problems here, since $ORIGIN/../lib won't work and the full paths are meant to be omitted. I consider this not great. I think, really, we should be able to dynamically link everything really, including cm3. I don't think we should static link just to make up for the need for a backup. There are plenty of backups available and you can make plenty more. However this will have to wait and probably take more arguing and maybe demonstration of its viability. I will require some work to make work anyway. At one point I was confused about the need for static linking so accepted it strongly. Now I don't see it. If you just need backups, again, they exist, and you can make more. Static linking isn't imho a substitute for backups. There are technical problems to be solved though. Could be that these issues are related though. If your backup might load the wrong m3core.so too easily, making it not a very reliable backup, static linking could mitigate that. But $origin seems like a good mitigation. I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath. That way you can just put everything in one messy but easier to move/copy directory. - Jay > Date: Thu, 2 Jul 2009 20:04:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > Quoting Tony Hosking : > > > That sounds plausible. Is there anything in the current setup that > > depends on the .so files being in pkg instead of lib? > > I don't think so offhand. But I must admit that I've lost the overview > in this area, too :-/ > > Olaf > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > >> How about we put .so files only in lib and not in pkg? Or symlink > >> from pkg to lib instead of how it used to be the other way around? > >> Those would also fix all this. > >> > >> - Jay (phone) > >> > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> > >>> > >>> Are you up to date in m3-libs/m3core? > >>> Lots of builds have succeeded with this.. > >>> It isn't great, but that requirement to build from previous 5.4 release.. > >>> > >>> - Jay > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] ROOT > >>>> > >>>> If I define ROOT then I get the following error. I think this all > >>>> needs reverting! > >>>> > >>>> --- building in SOLgnu --- > >>>> > >>>> ignoring ../src/m3overrides > >>>> > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > >>>> 12: quake runtime error: unable to copy > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > >>>> "./UnixLink.c": errno=2 > >>>> > >>>> --procedure-- -line- -file--- > >>>> cp_if -- > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > >>>> > >>>> Fatal Error: package build failed > >>>> n > >>>> > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > >>>> > >>>> Where did variable ROOT come from? Do I really need to define it? > >>>> Seems broken to me to depend on the source directory structure > >>>> as it sets that structure in stone. > >>>> > >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:48:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:48:00 +0000 Subject: [M3devel] ROOT In-Reply-To: <4A4CC4CE.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I'm completely agree that ROOT is too generic for an environment variable and it NOT required. It IS a quake variable though, and has long been. Nothing new there. At least if you ever use overrides. CM3_ROOT is in fact the other name. There are also quake variables INSTALLROOT and/or INSTALL_ROOT, I get those confused, and the environment variable CM3_INSTALL. I'm not a huge fan of the exact names actually, but they all/mostly were already there. I would have liked CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. I find ROOT and CM3_ROOT too ambiguous. But again, ROOT is quite old, to refer to the source and INSTALL_ROOT or INSTALLROOT is quite old to refer to the install. Hopefully my other mail will help clear this up. I agree this is all not easy to communicate. To some extent I just have to depend on people knowing that "How a file finds the .so files it uses?" Is a well known long standing dilemna and if you search the web you can find many people trying to explain aspects of it. Maybe I should put together some examples. However, I think I did. I think the ChangeLog explains it well. Let me check. no..must have been somewhere else. Anyway, search the web for $origin, ldd, -runpath, etc.... Try wading through the Apple, Sun, GNU/Linux ld man pages. They aren't pretty, I grant. I'll try to put together some examples maybe soon, maybe. Solaris has the nicer more verbose ldd and I'll be away over the weekend so no Solaris. I'd also like to do other Modula-3 work: 64 bit file sizes on all platforms I'm at least going to try. This might cascade too far and break a lot of things, since INTEGER and LONGINT cannot be freely intermixed, you can't even assign an INTEGER to a LONGINT! Merge gcc-interix with gcc. It turns out this is quite small. Enable the "portable runpaths" in Olaf's scripts (related to all this). I put the lines in slightly too far down in the code, oops. - Jay Date: Thu, 2 Jul 2009 14:31:45 -0400 From: rcolebur at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:51:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:51:22 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: darnit I need to be more careful. program -- not a shared library binary -- program or shared library in some contexts, but I used it below also to mean program shared library -- .dll, .so, etc. "I make no account for binaries in the pkg store" -- I meant programs. Darn I need to write this better...hopefully some of it will come through... - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 18:41:27 +0000 Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Before I explain, more options: copy and commit the source to cm3 is viable heck, use a relative instead of absolute from ROOT go back to the old way (I'll explain) There is also the option to relink or "fixup" upon ship and/or install. Some platforms have a "fixup" utility for exactly "these reasons". MacOS X has one. The question is: How does program foo find libbar.so? At runtime. How does libbar.so find libfoo.so? There are a bewildering array of choices. They are combinable. It varies somewhat from platform by platform, but not much really. The main options are: 1: A full path written into program foo or libbar pointing to e.g. /usr/lib/libfoo.so. Actually this is usually separate libfoo.so and a list of directories that apply to all .so files. There isn't generally a matching up of directory to file, I think, but a "search path" aka "run path". 2: A relative path written into program foo or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. Again, the directories are split from the files. MacOS X doesn't have $ORIGIN by that name, but it has three similar things, like @executable_path. @executable_path goes way back and is presumably relative to the primary main executable. There are two other similar options. One is new in 10.5. Presumably one is relative to the reference. And maybe one is some concatenation of all directories anything found in so far? I don't know. The documenation was not clear to me. NetBSD prior to 5.0 doesn't have $ORIGIN. NT searches $PATH always. We put the .dlls in bin. Cygwin same. Approximately all other systems seem to support about the same $ORIGIN feature: OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?) The MacOS X feature is close enough to lump in. 3: Search $LD_LIBRARY_PATH or similar. This has a few different names. LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. Now, our historical implementation was - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, a path for every dependency The file formats are generally such that there are leaf file names separate from an array of directories to look in. A "normal" non-Modula-3 program would generally I assume have a prety small such array of directories. A "normal" Modula-3 program would have a fairly large array. As well, doing builds for distribution would often leave you with /tmp/cm3 which is a possible security problem. This definitely did occur. Now, again, there are many options, and they can be combined. Portability is perhaps a concern, but perhaps not so much, given today's landscape. Now, if we are to use relative paths, well, my understanding is that the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib, and not /usr/local/cm3/pkg/foo/linux etc. This way, files in lib and bin can point to $ORIGIN/../lib. Now, keep in mind, that unshipped binaries sometimes people like to work, as well, perhaps also programs (not shared libraies, as far as I know) buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. I know cm3 sits in there, though that copy isn't used. I make no account for binaries buried in the package store. I do make some account for unshipped binaries. By default the run paths we are recording in current config files are $ORIGIN/../lib:/usr/local/cm3/lib Not a bunch of paths into pkg, just two entries. The "security" issue still is present by default. But the run path is "prettier" and probably more efficient. When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3). This is controled by an environment variable, which I set in Olaf's scripts, but oops I think I set it too late. I'll fix that very very soon. To recap: - full paths - relative paths from $ORIGIN - LD_LIBRARY_PATH They each have advantages and disadvantages. $ORIGIN provides for a "movable" install. I can install to /usr/local/cm3, you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH. However if I want to move just some of the files, not the whole binary tree together, then $ORIGIN breaks down. If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do. You are left with full paths or LD_LIBRARY_PATH. Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such. Look on birch for example, it is /usr/local/cm3/lib. That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there. This demonstrated another problem in this area! $ORIGIN keeps things more tightly together, which you often want, sometimes might not not. LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not. I figure tightly point is the more common, but imagine if you just want to replace one file. Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install this way.) So, here now I'm rambling. I've laid out the options and /some/ of the disadvantages/advantages. There is no perfect solution, and the various solutions are combinable. I find combining them though, I start to get confused. Because you end up in a "probing" situation and you start wondering which supercedes which, and you just hope there aren't any "duplicates" so that the probe order is mostly moot (assuming there remain no duplicates). Somewhat clear? You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and investigate the various options and their effects. Solaris has a very nice and verbose ldd form. Now, the files in pkg. I consider it somewhat philosophically significant that "everything is in pkg". There is a well structured "repository" not a randomly organized bunch of files. I think. Maybe this is just a suggestion? You know, if they are hardlinks and we don't really use the ones in pkg, is there a point? Or, on the other hand, is the philosophy a big deal and we should go back to lib symlinking to pkg to appease the philosophy? "ship/install" certainly "likes" to put things in pkg. I don't think the option of using lib and not pkg is doable without builder changes. But that is doable. A few other folks here did pipe up some on this in the recent past and I think there was kinda sorta consensus that the old ways were not great (particularly 1) the big runpath 2) the runpath into /tmp) and the new ways maybe better, but I admit there was no clear consensus. I acted somewhat unilaterally. You know, I'm impatient and arrogant so... and Tinderbox is there to cause some restraint. There was definitely pushback on wanting unshipped binaries to keep working, which they largely do as a result of the discussion/pushback. As well, any unshipped binaries that we know we use in the build, like PklFonts, stubgen, m3bundle, we build standalone, to evade/avoid problems here, since $ORIGIN/../lib won't work and the full paths are meant to be omitted. I consider this not great. I think, really, we should be able to dynamically link everything really, including cm3. I don't think we should static link just to make up for the need for a backup. There are plenty of backups available and you can make plenty more. However this will have to wait and probably take more arguing and maybe demonstration of its viability. I will require some work to make work anyway. At one point I was confused about the need for static linking so accepted it strongly. Now I don't see it. If you just need backups, again, they exist, and you can make more. Static linking isn't imho a substitute for backups. There are technical problems to be solved though. Could be that these issues are related though. If your backup might load the wrong m3core.so too easily, making it not a very reliable backup, static linking could mitigate that. But $origin seems like a good mitigation. I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath. That way you can just put everything in one messy but easier to move/copy directory. - Jay > Date: Thu, 2 Jul 2009 20:04:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > Quoting Tony Hosking : > > > That sounds plausible. Is there anything in the current setup that > > depends on the .so files being in pkg instead of lib? > > I don't think so offhand. But I must admit that I've lost the overview > in this area, too :-/ > > Olaf > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > >> How about we put .so files only in lib and not in pkg? Or symlink > >> from pkg to lib instead of how it used to be the other way around? > >> Those would also fix all this. > >> > >> - Jay (phone) > >> > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > >> > >>> > >>> Are you up to date in m3-libs/m3core? > >>> Lots of builds have succeeded with this.. > >>> It isn't great, but that requirement to build from previous 5.4 release.. > >>> > >>> - Jay > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] ROOT > >>>> > >>>> If I define ROOT then I get the following error. I think this all > >>>> needs reverting! > >>>> > >>>> --- building in SOLgnu --- > >>>> > >>>> ignoring ../src/m3overrides > >>>> > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > >>>> 12: quake runtime error: unable to copy > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > >>>> "./UnixLink.c": errno=2 > >>>> > >>>> --procedure-- -line- -file--- > >>>> cp_if -- > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > >>>> > >>>> Fatal Error: package build failed > >>>> n > >>>> > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > >>>> > >>>> Where did variable ROOT come from? Do I really need to define it? > >>>> Seems broken to me to depend on the source directory structure > >>>> as it sets that structure in stone. > >>>> > >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 20:56:27 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 18:56:27 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: Here are some good links, other people trying to explain this stuff: http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the Avoiding LD_LIBRARY_PATH: The Options With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. LD_LIBRARY_PATH Seems Useful. What's the Problem? http://blogs.sun.com/rie/entry/hello_there Surfing With a Linker Alien http://blogs.sun.com/rie/entry/tt_ld_library_path_tt LD_LIBRARY_PATH - just say no A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: % ldd -s /usr/bin/date ... find object=libc.so.1; required by /usr/bin/date search path=/opt/ISV/lib (LD_LIBRARY_PATH) If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"` The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) (2004-07-10 22:20:54.0) Permalink Comments [8] Comments: .... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:13:14 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:13:14 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: http://linuxmafia.com/faq/Admin/ld-lib-path.html Why setting LD_LIBRARY_PATH is considered harmful For the following reasons: LD_LIBRARY_PATH is used in preference to any run time or default system linker path. If (God forbid) you had it set to something like /dcs/spod/baduser/lib, if there was a hacked version of libc in that directory (for example) your account could be compromised. It is for this reason that set-uid programs completely ignore LD_LIBRARY_PATH. When code is compiled and depends on this to work, it can cause confusion where different versions of a library are installed in different directories, for example there is a libtiff in /usr/openwin/lib and /usr/local/lib. In this case, the former library is an older one used by some programs that come with Solaris. Sometimes when using precompiled binaries they may have been built with 3rd party libraries in specific locations; ideally code should either ship with the libraries and install into a certain location or link the code as a pre-installation step. Solaris 7 introduces $ORIGIN which allows for a relative library location to be specified at run time (see the Solaris Linker and Libraries Guide). The alternative is to set LD_LIBRARY_PATH on a per-program basis, either as a wrapper program to the real program or a shell alias. Note however, that LD_LIBRARY_PATH may be inherited by programs called by the wrapped one ... http://lists.trolltech.com/qt4-preview-feedback/2005-04/msg00648.html Requiring LD_LIBRARY_PATH is not a good idea imo. It's a variable meant to override defaults, not for the common case. If all packages on ours disks would require this variable hell would break loose. Ask a system administrator. .... different person... Unfortunately rpath is not a solution by itself (although it could be part of the solution). Having rpath point to the build directory is a security hole. It can be part of the solution though ..yet another...shades of things I have said here... Now you may argue that runMyAppUsingQtAndMyLib needs to be re-linked deployment anyway. I agree that's what some programs do or should do (some have even suggested to distribute *.o files and relink them on the target platform using an adequate rpath, but that's a bad idea since the linker may be unpatched and the C++ compiler broken on the target platform). Some users won't relink though. Shouldn't Qt protect them by default? What do you think? http://lists.apple.com/archives/Unix-porting/2005/May/msg00034.html As others have pointed out there is not really an equivalent of LD_LIBRARY_PATH because the whole shared library system is unique to MacOS X/Darwin. I think it is fair to say that if you find yourself using DYLD_LIBRARY_PATH except for testing uninstalled binaries, then you are doing it wrong. Every executable file on Darwin contains the full paths of the libraries against which it was linked, and these are used first by dyld at runtime. They can be changed after linking. (see docs about install_name) So you should never need to specify some odd DYLD_LIBRARY_PATH with a properly installed library wherever it is installed. So now maybe I should search the web for negative comments about $origin? Well, when I try "what is wrong with ld $origin" I again find criticism of LD_LIBRARY_PATH. :) Ok, I admit I didn't look very hard. I'll look more later. So you see, the point is, there is a lot stuff out there discouraging LD_LIBRARY_PATH and encouraging full paths and/or $origin. Including Sun's linker developer(s). Full paths are ok for us, to the symlinks, if we then have full paths within the files. But if we use $origin, then the pkg store bites us. Is some of this making sense? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 18:56:27 +0000 Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Here are some good links, other people trying to explain this stuff: http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the Avoiding LD_LIBRARY_PATH: The Options With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. LD_LIBRARY_PATH Seems Useful. What's the Problem? http://blogs.sun.com/rie/entry/hello_there Surfing With a Linker Alien http://blogs.sun.com/rie/entry/tt_ld_library_path_tt LD_LIBRARY_PATH - just say no A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: % ldd -s /usr/bin/date ... find object=libc.so.1; required by /usr/bin/date search path=/opt/ISV/lib (LD_LIBRARY_PATH) If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"` The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) (2004-07-10 22:20:54.0) Permalink Comments [8] Comments: .... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:23:55 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: [M3devel] ROOT In-Reply-To: <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:30:22 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:30:22 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: Btw, I must say, that Modula-3 often bucks the trend, often with reason and benefit. However the "trend" has a lot of people behind it, using it, fixing it, making sure it works. The "trend", the popular practice, would include put the files in /usr/local/cm3/lib and not pkg. Or, well, pkg could be an unused copy, but that's fairly pointless and wasteful. My use of hardlinks is not exactly "trendy". But I was kinda sorta not breaking the "pkg philosophy". It's like the putting an extra unused copy in pkg, but without much space wastage (just directory entries) At least then the whole symlink/root thing can go away at least. Though just using a relative path to get the source file or copying and commiting a smaller piece of it, would be ok..if someone wants hardlink primitive in cm3 for some reason still. The runpath won't be huge then also, no matter how all the other debating goes. I need some time to settle down and think about it and /try it out/ but at the moment I'm tempted by the ditching of pkg for .so files and just them in lib. It will require probably new builder and config file changes. Really the current hardlink solution is extremely close to this, but again, also not "trendy". .a/.sa files would remain where they are, in pkg, though, of course, there is "very trendy" precedent against that too. And then, er...what is left in pkg? - Jay From: jay.krell at cornell.edu To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: Re: [M3devel] ROOT >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:37:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:37:45 -0400 Subject: [M3devel] ROOT In-Reply-To: <4A4CC4CE.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I think best would be for Jay to reprise his thinking on why all of this was needed. In general, I oppose hard links on the grounds that they are not trivially migrateable. Better to have relative symbolic links. If we can avoid the need for $origin by installing libraries in a fixed INSTALL_ROOT/lib directory (rather than the current symbolic links approach) then I prefer that. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 14:31, Randy Coleburn wrote: > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:47:23 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:47:23 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: I half agree. It'll be a few hours/days, maybe a week, but I'll take a stab at only putting the files in lib. I don't know if it'll be easy or not but I'll try. Therefore no hardlinks. But still $origin. Unless maybe there is consensus that install must be /usr/local/cm3, unless you build/link yourself, then you can chose. And the distribution building will have to be sure to...um...? Be done as root and impact the running system??? No.. Well, distribution building can make it work somehow, by using -rpath /usr/local/cm3/lib, even if ld is pointed at /tmp/cm3/lib/libfoo.so. I can look into that, if there is actually firm consensus against $origin and for full paths, and for taking away user choice of install location...but...but....what about non-admin installs? They have to rebuild? As a non-admin installer on cm3, I can probably live with that, but not sure about others..seems not great. Another option is to link upon install, or "fixup" the paths on systems that can do that without relinking. Again I come back to favoring origin pretty strongly. Hard links seem perfectly migratable..they tar and untar at least.. I get it probably though -- what flags to use to cp? There are too many options, it confuses me. I know hard links can't cross file systems, but often people only hardlink "nearby" files that are the same file system anyway. Hardlinks don't survive on Windows FAT filesystem, probably nobody cares. They work fine on NTFS. Some copy utilities might break them though, yeah, that happens. Full paths not using $origin aren't migratable. - Jay From: hosking at cs.purdue.edu To: rcolebur at scires.com Date: Thu, 2 Jul 2009 15:37:45 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT I think best would be for Jay to reprise his thinking on why all of this was needed. In general, I oppose hard links on the grounds that they are not trivially migrateable. Better to have relative symbolic links. If we can avoid the need for $origin by installing libraries in a fixed INSTALL_ROOT/lib directory (rather than the current symbolic links approach) then I prefer that. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 14:31, Randy Coleburn wrote: I keep watching the various commit logs et al and I'm concerned too that I don't readily understand what is going on and what the new requirements will be going forward in terms of environment vars, paths, and config file requirements, etc. As for ROOT, as an environment var, this is too generic. If it is required, it should be renamed to be specific, e.g. CM3_ROOT. Would it be possible to have a online conference about all this? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:48:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:48:14 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> On 2 Jul 2009, at 14:41, Jay wrote: > Before I explain, more options: > > copy and commit the source to cm3 is viable I don't know what this sentence means. > heck, use a relative instead of absolute from ROOT ditto > go back to the old way (I'll explain) I think I understand the shortcomings here but Jay should explain. > There is also the option to relink or "fixup" > upon ship and/or install. Some platforms have a "fixup" > utility for exactly "these reasons". > MacOS X has one. Sounds feasible, but I worry about portability of this approach. > The question is: > > How does program foo find libbar.so? > At runtime. Right. rpaths in the executable should do the trick. > How does libbar.so find libfoo.so? Same again. > There are a bewildering array of choices. > They are combinable. > It varies somewhat from platform by platform, but not much really. Ideally we use the same approach for *all* platforms. So, what do all platforms have in common. > The main options are: > > > 1: A full path written into program foo > or libbar pointing to e.g. /usr/lib/libfoo.so. > Actually this is usually separate libfoo.so and > a list of directories that apply to all .so files. > There isn't generally a matching up of directory to file, > I think, but a "search path" aka "run path". i.e., rpath? > 2: A relative path written into program foo > or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so. > Again, the directories are split from the files. Please explain the implications of this w.r. to hard links! I don't want hard links. > MacOS X doesn't have $ORIGIN by that name, but it > has three similar things, like @executable_path. > @executable_path goes way back and is presumably > relative to the primary main executable. Then we should avoid $ORIGIN. Use the linker options to specify rpaths (and if there is need for override use $LD_LIBRARY_PATH. > There are two other similar options. > One is new in 10.5. Presumably one is relative > to the reference. And maybe one is some concatenation > of all directories anything found in so far? I don't know. > The documenation was not clear to me. Again, I'd like to use the same approach on all platforms (except perhaps Windows). > NetBSD prior to 5.0 doesn't have $ORIGIN. A good reason not to use it. > NT searches $PATH always. > We put the .dlls in bin. > Cygwin same. OK, so things work fine there. > Approximately all other systems seem to support about the same > $ORIGIN feature: > OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and > others (Aix? Irix? HP-UX?) > The MacOS X feature is close enough to lump in. > > 3: Search $LD_LIBRARY_PATH or similar. > This has a few different names. > LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING. These are fallbacks for the situation when the default installed configuration needs overriding. > Now, our historical implementation was > - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so, > a path for every dependency > The file formats are generally such that there are leaf file names > separate from an array of directories to look in. A "normal" > non-Modula-3 program would generally I assume have a prety small > such array of directories. A "normal" Modula-3 program would have > a fairly large array. But if everything goes in INSTALL_ROOT/lib we have only one directory, right? > As well, doing builds for distribution would often leave you with / > tmp/cm3 > which is a possible security problem. This definitely did occur. Surely, building for a distro can build in the right path. Where did / tmp/cm3 come from? If you need to be able to override while building then use $LD_LIBRARY_PATH. > Now, again, there are many options, and they can be combined. > Portability is perhaps a concern, but perhaps not so much, given > today's landscape. Elegance is also a concern. > Now, if we are to use relative paths, well, my understanding is that > the "real" files need to be in relatively few directories, e.g. /usr/ > local/cm3/lib, > and not /usr/local/cm3/pkg/foo/linux etc. I prefer this approach. > This way, files in lib and bin can point to $ORIGIN/../lib. Fair enough. > Now, keep in mind, that unshipped binaries sometimes people like to > work, > as well, perhaps also programs (not shared libraies, as far as I know) > buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo. > I know cm3 sits in there, though that copy isn't used. I don't know understand what you are trying to say here. > I make no account for binaries buried in the package store. > > I do make some account for unshipped binaries. > > By default the run paths we are recording in current config files > are > $ORIGIN/../lib:/usr/local/cm3/lib > Not a bunch of paths into pkg, just two entries. > > > The "security" issue still is present by default. > But the run path is "prettier" and probably more efficient. > > > When you build a distribution however, you are expected to omit /usr/ > local/cm3/lib (it might be /tmp/cm3). > This is controled by an environment variable, which I set in Olaf's > scripts, but oops > I think I set it too late. I'll fix that very very soon. The following is a bit rambling for me to respond to in detail. Perhaps someone else should weigh in. > > > To recap: > - full paths > - relative paths from $ORIGIN > - LD_LIBRARY_PATH > > They each have advantages and disadvantages. > $ORIGIN provides for a "movable" install. I can install to /usr/ > local/cm3, > you can install to /opt/cm3. It'll just work. No need to change > LD_LIBRARY_PATH. > > > However if I want to move just some of the files, not the whole > binary tree > together, then $ORIGIN breaks down. > > > If really want one file here, another there, and another somewhere > else, $ORIGIN doesn't do. > You are left with full paths or LD_LIBRARY_PATH. > > > Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or > such. > Look on birch for example, it is /usr/local/cm3/lib. > That tripped me up actually, because, you know, my cm3 is in $HOME/ > cm3 there. > This demonstrated another problem in this area! > $ORIGIN keeps things more tightly together, which you often want, > sometimes might not not. > LD_LIBRARY_PATH lets things be spread around, again, sometimes you > want that, sometimes not. > I figure tightly point is the more common, but imagine if you just > want to replace one file. > Is that reasonable? You replace it by putting it elsewhere? > (Imagine "patching" an install > this way.) > > > So, here now I'm rambling. > I've laid out the options and /some/ of the disadvantages/advantages. > > > There is no perfect solution, and the various solutions are > combinable. > I find combining them though, I start to get confused. > Because you end up in a "probing" situation and you start wondering > which supercedes which, and you just hope there aren't any > "duplicates" > so that the probe order is mostly moot (assuming there remain no > duplicates). > > > Somewhat clear? > > > You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo > or ldd -v or -V foo and > investigate the various options and their effects. Solaris has a > very nice and verbose > ldd form. > > > Now, the files in pkg. > I consider it somewhat philosophically significant that "everything > is in pkg". > There is a well structured "repository" not a randomly organized > bunch of files. > I think. Maybe this is just a suggestion? > You know, if they are hardlinks and we don't really use the ones in > pkg, is > there a point? > > > Or, on the other hand, is the philosophy a big deal and we should go > back to > lib symlinking to pkg to appease the philosophy? > > > "ship/install" certainly "likes" to put things in pkg. > I don't think the option of using lib and not pkg is doable without > builder changes. > But that is doable. > > > A few other folks here did pipe up some on this in the recent past and > I think there was kinda sorta consensus that the old ways were not > great > (particularly 1) the big runpath 2) the runpath into /tmp) > and the new ways maybe better, but I admit there was no clear > consensus. > I acted somewhat unilaterally. You know, I'm impatient and arrogant > so... > and Tinderbox is there to cause some restraint. > > > There was definitely pushback on wanting unshipped binaries to keep > working, > which they largely do as a result of the discussion/pushback. > > > As well, any unshipped binaries that we know we use in the build, > like PklFonts, > stubgen, m3bundle, we build standalone, to evade/avoid problems here, > since $ORIGIN/../lib won't work and the full paths are meant to be > omitted. > I consider this not great. > > I think, really, we should be able to dynamically link everything > really, > including cm3. I don't think we should static link just to make up for > the need for a backup. There are plenty of backups available and you > can > make plenty more. However this will have to wait and probably take > more arguing and maybe demonstration of its viability. > I will require some work to make work anyway. > > > At one point I was confused about the need for static linking so > accepted it strongly. > Now I don't see it. If you just need backups, again, they exist, and > you can make more. > Static linking isn't imho a substitute for backups. > There are technical problems to be solved though. > > Could be that these issues are related though. If your backup might > load the wrong m3core.so too easily, making it not a very reliable > backup, > static linking could mitigate that. But $origin seems like a good > mitigation. > I'm strongly considering add just plain $origin, in addition to > $origin/../lib to runpath. > That way you can just put everything in one messy but easier to move/ > copy directory. > > > - Jay > > > > > > > Date: Thu, 2 Jul 2009 20:04:36 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] ROOT > > > > Quoting Tony Hosking : > > > > > That sounds plausible. Is there anything in the current setup that > > > depends on the .so files being in pkg instead of lib? > > > > I don't think so offhand. But I must admit that I've lost the > overview > > in this area, too :-/ > > > > Olaf > > > > > On 2 Jul 2009, at 13:34, jay.krell at cornell.edu wrote: > > > > > >> How about we put .so files only in lib and not in pkg? Or symlink > > >> from pkg to lib instead of how it used to be the other way > around? > > >> Those would also fix all this. > > >> > > >> - Jay (phone) > > >> > > >> On Jul 2, 2009, at 9:21 AM, Jay wrote: > > >> > > >>> > > >>> Are you up to date in m3-libs/m3core? > > >>> Lots of builds have succeeded with this.. > > >>> It isn't great, but that requirement to build from previous > 5.4 release.. > > >>> > > >>> - Jay > > >>> > > >>> ________________________________ > > >>>> From: hosking at cs.purdue.edu > > >>>> To: hosking at cs.purdue.edu > > >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400 > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] ROOT > > >>>> > > >>>> If I define ROOT then I get the following error. I think this > all > > >>>> needs reverting! > > >>>> > > >>>> --- building in SOLgnu --- > > >>>> > > >>>> ignoring ../src/m3overrides > > >>>> > > >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line > > >>>> 12: quake runtime error: unable to copy > > >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to > > >>>> "./UnixLink.c": errno=2 > > >>>> > > >>>> --procedure-- -line- -file--- > > >>>> cp_if -- > > >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ > m3makefile > > >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args > > >>>> > > >>>> Fatal Error: package build failed > > >>>> n > > >>>> > > >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote: > > >>>> > > >>>> Where did variable ROOT come from? Do I really need to define > it? > > >>>> Seems broken to me to depend on the source directory structure > > >>>> as it sets that structure in stone. > > >>>> > > >>>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:52:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:52:38 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: <86309DFE-9D46-4092-AE9D-B94BA88234E8@cs.purdue.edu> On 2 Jul 2009, at 14:48, Jay wrote: > Hopefully my other mail will help clear this up. Jay, it's generally best to confine yourself to one e-mail instead of multiple. My (mental) bandwidth is saturated by the number of e-mails I must read in a day, so I can't keep track of all of yours. > I'd also like to do other Modula-3 work: > 64 bit file sizes on all platforms > I'm at least going to try. This might cascade too far and break > a lot of things, since INTEGER and LONGINT cannot be freely > intermixed, you can't even assign an INTEGER to a LONGINT! You can convert an INTEGER to a LONGINT. It is deliberate that INTEGER and LONGINT be unrelated types, in keeping with the spirit of M3. Implicit C casts are notorious sources of bugs. > Merge gcc-interix with gcc. It turns out this is quite small. > > Enable the "portable runpaths" in Olaf's scripts (related to all > this). > I put the lines in slightly too far down in the code, oops. Olaf, can you help clarify? > > > > - Jay > > Date: Thu, 2 Jul 2009 14:31:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 21:59:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 15:59:25 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> Message-ID: <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 21:59:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 19:59:50 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> Message-ID: > copy and commit the source to cm3 is viable > I don't know what this sentence means. I don't have to be copying files around in the build order for cm3 to create hard links. I can just copy on my machine and commit to cvs a little bit of code to do it. That isn't nearly as hacky. > heck, use a relative instead of absolute from ROOT > ditto $origin it turns out is very portable. Every system we support except NetBSD 4.0 seems to have it, and even some we don't currently support. And NetBSD 5.0, which already released, has it. And MacOSX is plenty close enough. It is a matter of relative to the executable or the reference, and which OS version you support. I believe newer versions relaly do have $origin by another name, but 10.4 has relative to the executable, which is good enough to me. If you don't use $origin, then people either must install to the one true place, or they must use LD_LIBRARY_PATH, or they must rebuild/relink/fixup themselves. LD_LIBRARY_PATH is widely panned. Having to rebuild seems onerous for most people. Having a choice of where to install? Important? > Right. rpaths in the executable should do the trick. Just in the executable? Shouldn't they somewhat be in the shared libraries? If foo uses libm3 and libm3 uses m3core and foo doesn't use m3core, arguably foo shouldn't mention m3core, only libm3 should. > Ideally we use the same approach for *all* platforms. So, what do all platforms have in common. $origin comes extremely close to that, and provides the benefit that user can specify where to install. > and if there is need for override use $LD_LIBRARY_PATH. But again (I know, I repeated myself, so you did, now I am), this forces any install to non-default location to use LD_LIBRARY_PATH. It is an option. But $origin is also /very/ portable... >> But if everything goes in INSTALL_ROOT/lib we have only one directory, right? Correct. That is what I achieved with the hardlinks, and will try to achieve shortly without them. > Surely, building for a distro can build in the right path. Not really. It would disrupt the running multiuser system. But it can probably use -rpath to stick paths in that don't correspond to the "staging" area. > Where did /tmp/cm3 come from? The distribution builds in /tmp. You don't have to be root or disrupt the running machine to build a distribution. There a question maybe of if the resulting files should be owned by root? > Elegance is also a concern. Agreed. Copying files in the build isn't elegant. The result is elegant imho. Hardlinks aren't elegant? I don't know. Anyway, ok, I'll just put the files in lib and no hardlinks, I'll try that. > Now, keep in mind, that unshipped binaries sometimes people like to work > I don't know understand what you are trying to say here. Let me think about unshipped binaries later.. One thing is that $origin doesn't work with unshipped binaries. By default we put in both $origin and the full path you like. But imho distributions should just have $origin. Or if user can't chose install location, maybe just the full path. The big question is if user can chose where to install. On birch I use $HOME/cm3. Seems kind of important/useful? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:02:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:02:56 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: Yes, now I remember. We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core. This implies the need for compilations upstream of m3core to function with both old and new versions. So, my question now is why did you introduce a dependency from the new cm3 to the new m3core? That should probably be avoided. On 2 Jul 2009, at 15:23, Jay wrote: > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:03:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:03:16 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> Message-ID: Ok, so I think a very important question is: >>> Should users have a choice of where to install? >>> What are the reasonable ramifications of someone who makes a non-default choice? /Personally/ I want the choice, esp. if I don't have root access!, and I don't want to set LD_LIBRARY_PATH. I want my choice and no negative consequences, and $origin basically gives me that. Except NetBSD prior to 5.0. 5.0 already released. And I guess Solaris prior to 2.7 or such. We do agree on a change vs. previous releases, at least. And it overlaps with what I did already. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 15:59:25 -0400 I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:05:25 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:05:25 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > why did you introduce a dependency to the new m3core I had removed link because it wasn't used, and/or didn't introduce it the first builds of e.g. AMD64_LINUX. Link naturally goes in m3core/src/unix. However implementing it locally in cm3 is reasonable. I should have tried harder on a clean local unshared solution. Not every .c file needs m3unix.h, though I am comforted by using it, that I have things all setup well and portably. Waitpid changes similar, you'll recall. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 16:02:56 -0400 Yes, now I remember. We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core. This implies the need for compilations upstream of m3core to function with both old and new versions. So, my question now is why did you introduce a dependency from the new cm3 to the new m3core? That should probably be avoided. On 2 Jul 2009, at 15:23, Jay wrote: >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:08:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:08:26 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: On 2 Jul 2009, at 15:30, Jay wrote: > Btw, I must say, that Modula-3 often bucks the trend, often with > reason and benefit. > However the "trend" has a lot of people behind it, using it, fixing > it, making sure it works. > The "trend", the popular practice, would include put the files in / > usr/local/cm3/lib and not pkg. I am fine with this. > Or, well, pkg could be an unused copy, but that's fairly pointless > and wasteful. I don't know what the reasons were for putting them in the pkg directories in the first place. > My use of hardlinks is not exactly "trendy". > But I was kinda sorta not breaking the "pkg philosophy". Does anyone recall if there was any real "philosophy" here? > It's like the putting an extra unused copy in pkg, but without much > space wastage (just directory entries) > > At least then the whole symlink/root thing can go away at least. > Though just using a relative path to get the source file or copying > and commiting a smaller piece of it, would be ok..if someone wants > hardlink primitive in cm3 for some reason still. I oppose hard links in general. > The runpath won't be huge then also, no matter how all the other > debating goes. > > > I need some time to settle down and think about it and /try it out/ > but at the moment I'm tempted by the ditching of pkg for .so files > and just them in lib. It will require probably new builder and > config file changes. RIght. > Really the current hardlink solution is extremely close to this, but > again, also not "trendy". > .a/.sa files would remain where they are, in pkg, though, of course, > there is "very trendy" precedent against that too. I suspect that the "pkg" philosophy dates from before .so shared libraries were even supported on most targets (yes, I can remember that long ago). > And then, er...what is left in pkg? Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). > > - Jay > > From: jay.krell at cornell.edu > To: jay.krell at cornell.edu; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 19:23:55 +0000 > Subject: Re: [M3devel] ROOT > > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:17:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:17:54 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> Message-ID: <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> On 2 Jul 2009, at 16:03, Jay wrote: > Ok, so I think a very important question is: > > >>> Should users have a choice of where to install? Yes! > >>> What are the reasonable ramifications of someone who makes a > non-default choice? > > /Personally/ I want the choice, esp. if I don't have root access!, > and I don't want to set LD_LIBRARY_PATH. > I want my choice and no negative consequences, and $origin basically > gives me that. > Except NetBSD prior to 5.0. 5.0 already released. > And I guess Solaris prior to 2.7 or such. > > > We do agree on a change vs. previous releases, at least. > And it overlaps with what I did already. I think so. (I just didn't like the link stuff and I still don't understand what ROOT is there for). > > > - Jay > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 15:59:25 -0400 > > I agree, LD_LIBRARY_PATH should only be used by power-users in a > pinch during development. > > On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:19:41 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:19:41 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > And then, er...what is left in pkg? Sorry, that was an unfinished thought. Various other things left, none of them will move. You might argue to move .sa files, but doesn't really matter, leave it alone, unless it is super duper convenient to move them along with the .so. It might be, because of how build_standalone works, or maybe only out of laziness. Except .so.5 along with .so. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 2 Jul 2009 16:08:26 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] ROOT On 2 Jul 2009, at 15:30, Jay wrote: Btw, I must say, that Modula-3 often bucks the trend, often with reason and benefit. However the "trend" has a lot of people behind it, using it, fixing it, making sure it works. The "trend", the popular practice, would include put the files in /usr/local/cm3/lib and not pkg. I am fine with this. Or, well, pkg could be an unused copy, but that's fairly pointless and wasteful. I don't know what the reasons were for putting them in the pkg directories in the first place. My use of hardlinks is not exactly "trendy". But I was kinda sorta not breaking the "pkg philosophy". Does anyone recall if there was any real "philosophy" here? It's like the putting an extra unused copy in pkg, but without much space wastage (just directory entries) At least then the whole symlink/root thing can go away at least. Though just using a relative path to get the source file or copying and commiting a smaller piece of it, would be ok..if someone wants hardlink primitive in cm3 for some reason still. I oppose hard links in general. The runpath won't be huge then also, no matter how all the other debating goes. I need some time to settle down and think about it and /try it out/ but at the moment I'm tempted by the ditching of pkg for .so files and just them in lib. It will require probably new builder and config file changes. RIght. Really the current hardlink solution is extremely close to this, but again, also not "trendy". .a/.sa files would remain where they are, in pkg, though, of course, there is "very trendy" precedent against that too. I suspect that the "pkg" philosophy dates from before .so shared libraries were even supported on most targets (yes, I can remember that long ago). And then, er...what is left in pkg? Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). - Jay From: jay.krell at cornell.edu To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 2 Jul 2009 19:23:55 +0000 Subject: Re: [M3devel] ROOT >> But why would you compile a new cm3 with an old m3core? That is what the "release" builds do on the Tinderbox. If you can fix that, please do. :) Notice how I broke them the other day? But not the "last ok" build? They start with a 5.4 compiler. They do NOT build m3core, libm3. Not sure about m3cc. They start with sysutils, then, in whatever order, m3quake, m3middle, m3front, m3back, cm3. Then they use that new cm3 to build m3cc if not done already (clean) m3core, libm3, sysutils, m3front/quake/back/middle, cm3. At some point, you know, cm3 could not build m3core, when cm3 didn't know about LONGINT and m3core used it. I don't know if 5.4 is such a version. > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? That's not the entire story. If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then - you end up with a huge presumably inefficient runpath This can be addressed by using /usr/local/cm3/lib instead. - you end up with insecure /tmp for distribution builds This can be addressed by using $origin or changing how distribution builds are done. - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up. > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage? I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin. "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts. If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT Date: Thu, 2 Jul 2009 12:40:18 -0400 I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 2 Jul 2009, at 12:19, Jay wrote: Seems broken to me to depend on the source directory structure Like m3overrides? But yes, I agree. m3overrides seems broken too. - Jay ---------------------------------------- From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Thu, 2 Jul 2009 11:49:34 -0400 Subject: [M3devel] ROOT Where did variable ROOT come from? Do I really need to define it? Seems broken to me to depend on the source directory structure as it sets that structure in stone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:23:35 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:23:35 +0000 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> Message-ID: (I just didn't like the link stuff and I still don't understand what ROOT is there for). The point was to add Unix.link where it belongs, m3core, and use it from where can't depend on new m3core. And maybe go overboard in sharing the source, to a trivial one line function (less trivial on Win32, in order to support pre-Win2000 OS). The point was to put the files in lib and also leave them in pkg, without wasting space. The decision now, which I still have to try, is to stop putting the files in pkg, so then no hardlink needed. $origin vs. full paths is still debatable and I still convinced $origin is the way to go. I'm also inclined to put $origin and $origin/../lib in rpath, so backups can flatten the structure to just one directory: /backup/cm3 /backup/libm3core.so /backup/libm3.so in some /hypothetical future/ where cm3 is dynamically linked. As long there are no "duplicates" -- files in both bin and lib, the runpath remains fairly clear/unambiguous. And even then, the order is pretty clearly left to right.. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 16:17:54 -0400 On 2 Jul 2009, at 16:03, Jay wrote: Ok, so I think a very important question is: >>> Should users have a choice of where to install? Yes! >>> What are the reasonable ramifications of someone who makes a non-default choice? /Personally/ I want the choice, esp. if I don't have root access!, and I don't want to set LD_LIBRARY_PATH. I want my choice and no negative consequences, and $origin basically gives me that. Except NetBSD prior to 5.0. 5.0 already released. And I guess Solaris prior to 2.7 or such. We do agree on a change vs. previous releases, at least. And it overlaps with what I did already. I think so. (I just didn't like the link stuff and I still don't understand what ROOT is there for). - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. Date: Thu, 2 Jul 2009 15:59:25 -0400 I agree, LD_LIBRARY_PATH should only be used by power-users in a pinch during development. On 2 Jul 2009, at 14:56, Jay wrote: Here are some good links, other people trying to explain this stuff: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:24:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:24:08 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> Message-ID: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> On 2 Jul 2009, at 15:47, Jay wrote: > I half agree. ;-) > It'll be a few hours/days, maybe a week, but I'll take a stab at > only putting the files in lib. > I don't know if it'll be easy or not but I'll try. > Therefore no hardlinks. Cool! > But still $origin. I think so, but still not sure. > Unless maybe there is consensus that install must be /usr/local/ > cm3, unless you build/link yourself, then you can chose. My inclination is that a binary install (no build/link) is OK to be hardwired, but if $origin gives flexibility in that then perhaps worth supporting. But surely, for binary installs we will be using package managers to install to standard places so no need to adjust the paths? > And the distribution building will have to be sure to...um...? Be > done as root and impact the running system??? No.. > Well, distribution building can make it work somehow, by using - > rpath /usr/local/cm3/lib, even if ld is pointed at /tmp/cm3/lib/ > libfoo.so. I can look into that, if there is actually firm consensus > against $origin and for full paths, and for taking away user choice > of install location...but...but....what about non-admin installs? > They have to rebuild? As a non-admin installer on cm3, I can > probably live with that, but not sure about others..seems not great. > Another option is to link upon install, or "fixup" the paths on > systems that can do that without relinking. > Again I come back to favoring origin pretty strongly. OK, now I think I understand where you are coming from. You want binary installs (no build/link) for non-admin users to non-standard places. Seems like a desirable thing in theory. > Hard links seem perfectly migratable..they tar and untar at least.. > I get it probably though -- what flags to use to cp? There are too > many options, it confuses me. > I know hard links can't cross file systems, but often people only > hardlink "nearby" files that are the same file system anyway. > Hardlinks don't survive on Windows FAT filesystem, probably nobody > cares. They work fine on NTFS. > Some copy utilities might break them though, yeah, that happens. I generally avoid them because of the swamp you just described. > Full paths not using $origin aren't migratable. Right. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcolebur at scires.com > Date: Thu, 2 Jul 2009 15:37:45 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > I think best would be for Jay to reprise his thinking on why all of > this was needed. In general, I oppose hard links on the grounds > that they are not trivially migrateable. Better to have relative > symbolic links. If we can avoid the need for $origin by installing > libraries in a fixed INSTALL_ROOT/lib directory (rather than the > current symbolic links approach) then I prefer that. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 14:31, Randy Coleburn wrote: > > I keep watching the various commit logs et al and I'm concerned too > that I don't readily understand what is going on and what the new > requirements will be going forward in terms of environment vars, > paths, and config file requirements, etc. > > As for ROOT, as an environment var, this is too generic. If it is > required, it should be renamed to be specific, e.g. CM3_ROOT. > > Would it be possible to have a online conference about all this? > > Regards, > Randy Coleburn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:24:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:24:38 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: > I oppose hard links in general. Why? This is hypothetical/just-curious now, because we have agreed to take away the need I had for them. But then when I think I want them tomorrow again, what is the reason not? :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:25:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:25:03 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: <6FB1A21F-E26D-435D-AEE2-1C2337E92C09@cs.purdue.edu> On 2 Jul 2009, at 16:19, Jay wrote: > > And then, er...what is left in pkg? > > > Sorry, that was an unfinished thought. > Various other things left, none of them will move. > You might argue to move .sa files, but doesn't really matter, leave > it alone, unless it is super duper convenient to move them along > with the .so. It might be, because of how build_standalone works, or > maybe only out of laziness. > Except .so.5 along with .so. RIght. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 2 Jul 2009 16:08:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ROOT > > On 2 Jul 2009, at 15:30, Jay wrote: > > Btw, I must say, that Modula-3 often bucks the trend, often with > reason and benefit. > However the "trend" has a lot of people behind it, using it, fixing > it, making sure it works. > The "trend", the popular practice, would include put the files in / > usr/local/cm3/lib and not pkg. > > I am fine with this. > > Or, well, pkg could be an unused copy, but that's fairly pointless > and wasteful. > > I don't know what the reasons were for putting them in the pkg > directories in the first place. > > My use of hardlinks is not exactly "trendy". > But I was kinda sorta not breaking the "pkg philosophy". > > Does anyone recall if there was any real "philosophy" here? > > It's like the putting an extra unused copy in pkg, but without much > space wastage (just directory entries) > > At least then the whole symlink/root thing can go away at least. > Though just using a relative path to get the source file or copying > and commiting a smaller piece of it, would be ok..if someone wants > hardlink primitive in cm3 for some reason still. > > I oppose hard links in general. > > The runpath won't be huge then also, no matter how all the other > debating goes. > > > I need some time to settle down and think about it and /try it out/ > but at the moment I'm tempted by the ditching of pkg for .so files > and just them in lib. It will require probably new builder and > config file changes. > > RIght. > > Really the current hardlink solution is extremely close to this, but > again, also not "trendy". > .a/.sa files would remain where they are, in pkg, though, of course, > there is "very trendy" precedent against that too. > > I suspect that the "pkg" philosophy dates from before .so shared > libraries were even supported on most targets (yes, I can remember > that long ago). > > And then, er...what is left in pkg? > > Sources. For browsing by the various Modula-3 tools. Come to think > of it, that reminds me -- the package browsing tools (eg, m3browser) > rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, > this argues for only moving the .so files to INSTALL_ROOT/lib and > leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived > sources in the pkg/TARGET directories where they currently reside). > > > - Jay > > From: jay.krell at cornell.edu > To: jay.krell at cornell.edu; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 19:23:55 +0000 > Subject: Re: [M3devel] ROOT > > > >> But why would you compile a new cm3 with an old m3core? > > That is what the "release" builds do on the Tinderbox. > If you can fix that, please do. :) > Notice how I broke them the other day? > But not the "last ok" build? > > They start with a 5.4 compiler. > They do NOT build m3core, libm3. > Not sure about m3cc. > They start with sysutils, then, in whatever order, > m3quake, m3middle, m3front, m3back, cm3. > Then they use that new cm3 to build > m3cc if not done already > (clean) > m3core, libm3, sysutils, m3front/quake/back/middle, cm3. > > At some point, you know, cm3 could not build m3core, when > cm3 didn't know about LONGINT and m3core used it. > I don't know if 5.4 is such a version. > > > > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH? > > That's not the entire story. > If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then > - you end up with a huge presumably inefficient runpath > This can be addressed by using /usr/local/cm3/lib instead. > > - you end up with insecure /tmp for distribution builds > This can be addressed by using $origin or changing how > distribution builds are done. > > - You can't "easily" move the install. Though there are utilities > in various OSes to edit the paths later, or you can relink upon > install. I didn't make that strategy up. > > > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries > someplace other than the rpath used in their linkage? > > I don't understand. Right, if you want to move stuff around, > LD_LIBRARY_PATH is one solution. $origin is another. They aren't > equivalent and they have various pluses/minus. Searching the web > definitely leads me to favor $origin. > "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not > scoped to a particular executable, unless you use wrapper scripts. / > etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke > my own use of my $HOME/cm3/bin, because those binaries are supposed > to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, > again, unless you write wrapper scripts. > > If we force everyone to install to /usr/local/cm3 or /opt/cm3, the > issue is reduced, granted > > > - Jay > > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT > Date: Thu, 2 Jul 2009 12:40:18 -0400 > > I'm not talking about m3overrides. That is a arguably a special- > purpose hack. We shouldn't layer a hack into the *normal* build > process. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 2 Jul 2009, at 12:19, Jay wrote: > > > Seems broken to me to depend on > the source directory structure > > Like m3overrides? But yes, I agree. > m3overrides seems broken too. > > - Jay > > > > > > > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 2 Jul 2009 11:49:34 -0400 > Subject: [M3devel] ROOT > > Where did variable ROOT come from? Do I really need to define it? > Seems broken to me to depend on the source directory structure as it > sets that structure in stone. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 2 22:26:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Jul 2009 16:26:38 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <918ED746-1315-4E50-BBFF-BB96166853D8@cs.purdue.edu> Message-ID: <51053E7F-533F-4951-9E13-62122B2BB983@cs.purdue.edu> I think we are converging on a reasonable compromise (as noted in my other responses). On 2 Jul 2009, at 15:59, Jay wrote: > > copy and commit the source to cm3 is viable > > I don't know what this sentence means. > > I don't have to be copying files around in the build order for cm3 > to create hard links. > I can just copy on my machine and commit to cvs a little bit of code > to do it. > That isn't nearly as hacky. > > > heck, use a relative instead of absolute from ROOT > > ditto > > > $origin it turns out is very portable. > Every system we support except NetBSD 4.0 seems to have it, and > even some we don't currently support. > And NetBSD 5.0, which already released, has it. > And MacOSX is plenty close enough. It is a matter of relative to > the executable or the reference, and which OS version you support. I > believe newer versions relaly do have $origin by another name, but > 10.4 has relative to the executable, which is good enough to me. > > If you don't use $origin, then people either must install to the one > true place, or they must use LD_LIBRARY_PATH, or they must rebuild/ > relink/fixup themselves. > > LD_LIBRARY_PATH is widely panned. > Having to rebuild seems onerous for most people. > Having a choice of where to install? Important? > > > > Right. rpaths in the executable should do the trick. > > Just in the executable? Shouldn't they somewhat be in the shared > libraries? > If foo uses libm3 and libm3 uses m3core and foo doesn't use m3core, > arguably foo shouldn't mention m3core, only libm3 should. > > > > Ideally we use the same approach for *all* platforms. So, what > do all platforms have in common. > > $origin comes extremely close to that, and provides the benefit that > user can specify where to install. > > > > and if there is need for override use $LD_LIBRARY_PATH. > > But again (I know, I repeated myself, so you did, now I am), this > forces any install to non-default location to use LD_LIBRARY_PATH. > It is an option. But $origin is also /very/ portable... > > >> But if everything goes in INSTALL_ROOT/lib we have only one > directory, right? > > Correct. That is what I achieved with the hardlinks, and will try to > achieve shortly without them. > > > Surely, building for a distro can build in the right path. > > Not really. It would disrupt the running multiuser system. > But it can probably use -rpath to stick paths in that don't > correspond to the "staging" area. > > > > Where did /tmp/cm3 come from? > > The distribution builds in /tmp. You don't have to be root or > disrupt the running machine to build a distribution. > There a question maybe of if the resulting files should be owned by > root? > > > > Elegance is also a concern. > > Agreed. Copying files in the build isn't elegant. The result is > elegant imho. > Hardlinks aren't elegant? I don't know. > Anyway, ok, I'll just put the files in lib and no hardlinks, I'll > try that. > > Now, keep in mind, that unshipped binaries sometimes people like > to work > > I don't know understand what you are trying to say here. > > Let me think about unshipped binaries later.. > One thing is that $origin doesn't work with unshipped binaries. > By default we put in both $origin and the full path you like. > But imho distributions should just have $origin. > Or if user can't chose install location, maybe just the full path. > The big question is if user can chose where to install. > On birch I use $HOME/cm3. > Seems kind of important/useful? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:30:47 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:30:47 +0000 Subject: [M3devel] ROOT In-Reply-To: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: > But surely, for binary installs we will be using package managers to install to standard places so no need to adjust the paths? Yes and no. In fact, yes, I made some .deb files, and they have no choice of where to install. They have no "install code", beyond dpkg. But .deb files often do have install scripts in them. It's not a hard requirement to avoid. And the normal workflow with apt-get install doesn't give you a choice of install location either. Historically we don't have little/no use of package manages. Therefore open the other can of worms of what a binary install should look like... (Echoing Olaf here) There are way too many install formats, while it is nice for us to support some of them, it behooves us to have our own low end portable form, and we have some say in the feature set of it, such as if you can chose the install location. (We could also adopt one of the native ones as our portable one, if it is in fact portable; .deb it turns out is actually promising in this regard, it takes like two lines of .sh to install a .deb on pretty much any system, assuming the contents are for it; they are just a .tar.gz bundled with very little else in an ar file.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 19:34:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 10:34:55 -0700 Subject: [M3devel] ROOT In-Reply-To: References: Message-ID: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> How about we put .so files only in lib and not in pkg? Or symlink from pkg to lib instead of how it used to be the other way around? Those would also fix all this. - Jay (phone) On Jul 2, 2009, at 9:21 AM, Jay wrote: > > Are you up to date in m3-libs/m3core? > Lots of builds have succeeded with this.. > It isn't great, but that requirement to build from previous 5.4 > release.. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 2 Jul 2009 11:54:51 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ROOT >> >> If I define ROOT then I get the following error. I think this all >> needs reverting! >> >> --- building in SOLgnu --- >> >> ignoring ../src/m3overrides >> >> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line 12: >> quake runtime error: unable to copy "~/cm3/m3-libs/m3core/src/unix/ >> Common/UnixLink.c" to "./UnixLink.c": errno=2 >> >> --procedure-- -line- -file--- >> cp_if -- >> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ >> m3makefile >> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args >> >> Fatal Error: package build failed >> n >> >> On 2 Jul 2009, at 11:49, Tony Hosking wrote: >> >> Where did variable ROOT come from? Do I really need to define it? >> Seems broken to me to depend on the source directory structure as >> it sets that structure in stone. >> >> From jay.krell at cornell.edu Thu Jul 2 22:35:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:35:20 +0000 Subject: [M3devel] ROOT In-Reply-To: <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: > You want binary installs (no build/link) for non-admin users to non-standard places Right, and without having to set LD_LIBRARY_PATH (except on NetBSD 4.0 :) ) "What is the cost of a non-default install location?" - Jay From: hosking at cs.purdue.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 22:39:13 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 2 Jul 2009 20:39:13 +0000 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: In the meantime btw, I assert things are broken. Consider putting it all back as it was. Tonight I can try using a relative path instead of ROOT, as a baby step. Or I can commit the code so that build doesn't copy it. Or we can have cm3 depend on m3core and leave "release" broken for a bit. As I said, I wouldn't mind relaxing that requirement (I suspect Olaf disagrees strongly though.) Or you can finish the reversion by lookin for "hardlink" in the config files and changing it to just "link". That might work. Might. Really, more so, look for the uses of $origin and remove them too. I really need to run catch a plain and spend time with family though. Later, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 2 23:02:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 14:02:48 -0700 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: I can put if back tonight and then remove 'root' and then hardlinks will remain temporarily. - Jay (phone) On Jul 2, 2009, at 1:39 PM, Jay wrote: > In the meantime btw, I assert things are broken. > > Consider putting it all back as it was. > > Tonight I can try using a relative path instead of ROOT, as a baby > step. > Or I can commit the code so that build doesn't copy it. > > Or we can have cm3 depend on m3core and leave "release" broken for a > bit. > As I said, I wouldn't mind relaxing that requirement (I suspect Olaf > disagrees strongly though.) > > Or you can finish the reversion by lookin for "hardlink" in the > config files and changing it to just "link". > That might work. Might. > Really, more so, look for the uses of $origin and remove them too. > > > I really need to run catch a plain and spend time with family though. > > > Later, > - Jay From jay.krell at cornell.edu Thu Jul 2 23:04:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 14:04:40 -0700 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: (and keep it compatible with old cm3) - Jay (phone) On Jul 2, 2009, at 2:02 PM, jayk123 at hotmail.com wrote: > I can put if back tonight and then remove 'root' and then hardlinks > will remain temporarily. > > - Jay (phone) > > On Jul 2, 2009, at 1:39 PM, Jay wrote: > >> In the meantime btw, I assert things are broken. >> >> Consider putting it all back as it was. >> >> Tonight I can try using a relative path instead of ROOT, as a baby >> step. >> Or I can commit the code so that build doesn't copy it. >> >> Or we can have cm3 depend on m3core and leave "release" broken for >> a bit. >> As I said, I wouldn't mind relaxing that requirement (I suspect >> Olaf disagrees strongly though.) >> >> Or you can finish the reversion by lookin for "hardlink" in the >> config files and changing it to just "link". >> That might work. Might. >> Really, more so, look for the uses of $origin and remove them too. >> >> >> I really need to run catch a plain and spend time with family though. >> >> >> Later, >> - Jay From rcolebur at scires.com Thu Jul 2 23:54:51 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 17:54:51 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> Message-ID: <4A4CF46A.1E75.00D7.1@scires.com> Also, let us not forget about CM3IDE (formerly Reactor). It can browse multiple repositories, some marked public and some marked private. We don't want to introduce changes in the way stuff is shipped that would break CM3IDE or M3BROWSER. I think the browsing capabilities in CM3IDE are an outgrowth of the old m3browser and expand upon it to show dependencies, lists of interfaces/implementions imported/exported, etc. etc. CM3IDE also relies on knowledge of the cm3 file tree to locate stuff and to create new packages, etc. If we muck around too much with all of this, we risk breaking CM3IDE or at least having to adapt it to whatever new structure/rules are in place. Regards, Randy Coleburn >>> Tony Hosking 7/2/2009 4:08 PM >>> Sources. For browsing by the various Modula-3 tools. Come to think of it, that reminds me -- the package browsing tools (eg, m3browser) rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, this argues for only moving the .so files to INSTALL_ROOT/lib and leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources in the pkg/TARGET directories where they currently reside). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jul 3 00:19:15 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 15:19:15 -0700 Subject: [M3devel] ROOT In-Reply-To: <4A4CF46A.1E75.00D7.1@scires.com> References: <157E26FC-82FD-4EA8-A7B7-C8F887294CE5@cs.purdue.edu> <51C895AD-C0E4-420F-9973-FD339C0A43F0@hotmail.com> <4A4CF46A.1E75.00D7.1@scires.com> Message-ID: <56A22159-9AB8-4A47-B5BF-3812A45051B4@hotmail.com> Ok. I doubt IDE cares about this and we can make symlinks on most platforms. We will not move .m3web .m3exports .m3x etc. - Jay (phone) On Jul 2, 2009, at 2:54 PM, "Randy Coleburn" wrote: > Also, let us not forget about CM3IDE (formerly Reactor). It can > browse multiple repositories, some marked public and some marked > private. We don't want to introduce changes in the way stuff is > shipped that would break CM3IDE or M3BROWSER. I think the browsing > capabilities in CM3IDE are an outgrowth of the old m3browser and > expand upon it to show dependencies, lists of interfaces/ > implementions imported/exported, etc. etc. CM3IDE also relies on > knowledge of the cm3 file tree to locate stuff and to create new > packages, etc. If we muck around too much with all of this, we risk > breaking CM3IDE or at least having to adapt it to whatever new > structure/rules are in place. > Regards, > Randy Coleburn > > >>> Tony Hosking 7/2/2009 4:08 PM >>> > Sources. For browsing by the various Modula-3 tools. Come to think > of it, that reminds me -- the package browsing tools (eg, m3browser) > rely on the .M3EXPORTS and .M3WEB files in the pkg directories. So, > this argues for only moving the .so files to INSTALL_ROOT/lib and > leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived > sources in the pkg/TARGET directories where they currently reside). From rcolebur at scires.com Fri Jul 3 01:14:58 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Thu, 2 Jul 2009 19:14:58 -0400 Subject: [M3devel] ROOT In-Reply-To: References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> Message-ID: <4A4D0732.1E75.00D7.1@scires.com> I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release. 1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms. 2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. 3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure: +---foo | +---src | +---NT386 | +---HPPA | \---(...) 4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) 5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure: CM3 +---bin +---doc | +---help | +---pics | +---reference | +---src_reports | \---tutorial +---examples +---lib +---pkg | +---bitvector | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---cm3ide | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---(...) | | +---src | | +---NT386 | | +---HPPA | | \---(...) 6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly. 7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken. 8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed. Hope this info is helpful. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jul 3 03:50:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:50:55 -0700 Subject: [M3devel] ROOT In-Reply-To: <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> Message-ID: <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> In particular I would argue that the directory layout should be made right at link time, into an alternate root. That alternate root possibly be prepopulated with links to or copies of the current good shared repository. Or the compiler should have notion of multiple roots to probe. However running the stuff implies hardlinks that are broken upon write. This scheme works better if source/interfaces are not needed in repository, just to cut down on the size. Are shipped source/interfaces used by compiler, or just the .m3exports/.m3x files? Anyway this is all thinking for a future release, not this year. 'ship' becomes just recursive copy or move.or change roots, plus maybe shipping source/interfaces too, kind of a wart. - Jay (phone) On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > The system used/uses symlinks under the covers. I don't think cm3 > historically supported shared libs on hpux probably because the > bundled compiler does not. Granted my exposure to hpux is only in > recent times. 'standalone' as you define is useful but I think that > reason isn't applicable to anything 'within cm3 itself'. Maybe more > to say later. In particular I think this design we have is flawed. > It's goals are good but can be better achieved slightly differently. > In particular the unshipped and shipped directory layout should be > 'the same' but just differently rooted. Not in this release though. > That let's $origin work better, among other advantages. Related and > possibly solved same IMHO we don't adequately separate source and > output - it should separate across multiple packages not just one at > a time. But again, not on this release. > > - Jay (phone) > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" > wrote: > >> I thought it might be helpful to highlight some of what I've always >> understood as the design for the CM3 package system. So, I pulled >> out my old documentation from Critical Mass as reference. >> >> I offer the following information to see if this discussion thread >> concurs and/or wants to make any changes going forward, esp. as we >> prepare for a new CM3 release. >> >> 1. CM3 takes care to separate source and derived files because >> doing so (a) isolates source files for backup, revision control, >> and searching; and (b) enables sharing the same source tree across >> operating systems and architectures, without confusing object files >> from different platforms. >> >> 2. Each package resides in a directory, with sources in a source >> subdirectory ("src"), and generated files in a derived subdirectory >> named to denote the platform on which the sources were built, e.g., >> "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. >> >> 3. Each developer can have multiple private packages, each stored >> wherever desired in the filesystem. A private package named "foo" >> would have the following filesystem structure: >> +---foo >> | +---src >> | +---NT386 >> | +---HPPA >> | \---(...) >> >> 4. For each CM3 installation, there is one public package >> repository that is available to all developers. When you ship a >> [private] package, you make that package available to other >> packages (and developers) via this public package repository. The >> idea is that as a developer you would test your package in your >> private repository before shipping it to the public repository. >> (Sometimes m3overrides were needed when testing several related >> private packages before shipping them.) >> >> 5. A typical CM3 installation is rooted at a given point in the >> file system and contains the following folder structure: >> CM3 >> +---bin >> +---doc >> | +---help >> | +---pics >> | +---reference >> | +---src_reports >> | \---tutorial >> +---examples >> +---lib >> +---pkg >> | +---bitvector >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> | +---cm3ide >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> | +---(...) >> | | +---src >> | | +---NT386 >> | | +---HPPA >> | | \---(...) >> >> 6. In the past, the environment variable INSTALL_ROOT pointed to >> the root of the CM3 tree in the file system. I think this variable >> is ambiguously named and that we should change it to >> CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 >> installations (perhaps for different releases), one would simply >> need to change the CM3_INSTALL_ROOT variable to point to the >> desired installation for use at any particular point in time. For >> this to work, all other variables cue off of CM3_INSTALL_ROOT. I >> know that for the old cm3.cfg file, this was indeed the behavior. >> Then, if someone had a special situation, they could override the >> "cueing" behavior for any particular variable simply by changing >> its definition on the fly. >> >> 7. Now, I also understand some (but not all) of what Jay is saying >> about the library paths. Back in the old cm3 v4.1 days, I had both >> HPPA and NT386 derived files for the same set of sources. For >> Windows, the shipped exe and dll files went into the public >> repository and you needed to have the CM3/bin folder on your path. >> For private exe and dlls, you typically just ran them out of the >> private package's derived NT386 folder. On HPPA, there were some >> places in the file system that contained static libraries and >> shared libraries, plus then you had the libraries built using CM3. >> Again, the CM3 libraries went to the public repository and there >> were environment variables to facilitate finding the rest, >> including LD_LIBRARY_PATH. Now, from what Jay is saying, the >> variety of operating environments seems to cloud up all this. I >> know I'm a bit rusty wrt all the various unix variants out there, >> but I recall that v4.1 worked out-of-the-box for both NT386 and >> HPPA with respect to all this library path stuff and I didn't have >> to make any symbolic links nor any hard links to make it work. >> IMO, links are bad and too easily broken. >> >> 8. As for "build_standalone", I know there are various build/ >> bootstrap reasons why some parts of CM3 had to be built this way. >> But, for me, I've often used this feature for utility-type programs >> to make it easier to distribute them. I can simply distribute the >> one executable file without having to worry that the target system >> might not have the right DLLs or the right shared libraries in the >> right locations. For production code, I've always built an >> installation program or an installation script that installed all >> my executables and shared libraries in a folder structure rooted at >> a particular point chosen by the end user. Then, my programs >> always launched and used relative paths from the install location >> to find everything they needed. >> >> Hope this info is helpful. >> >> Regards, >> Randy Coleburn >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 03:57:38 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:57:38 -0700 Subject: [M3devel] ROOT In-Reply-To: <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> Message-ID: <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> Ps this would also obsolete m3overrides, providing similar but better functionality, no need to encode the source structure in all those little extra files. - Jay (phone) On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > In particular I would argue that the directory layout should be made > right at link time, into an alternate root. That alternate root > possibly be prepopulated with links to or copies of the current good > shared repository. Or the compiler should have notion of multiple > roots to probe. However running the stuff implies hardlinks that are > broken upon write. This scheme works better if source/interfaces are > not needed in repository, just to cut down on the size. Are shipped > source/interfaces used by compiler, or just the .m3exports/.m3x > files? Anyway this is all thinking for a future release, not this > year. 'ship' becomes just recursive copy or move.or change roots, > plus maybe shipping source/interfaces too, kind of a wart. > > - Jay (phone) > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > >> The system used/uses symlinks under the covers. I don't think cm3 >> historically supported shared libs on hpux probably because the >> bundled compiler does not. Granted my exposure to hpux is only in >> recent times. 'standalone' as you define is useful but I think that >> reason isn't applicable to anything 'within cm3 itself'. Maybe more >> to say later. In particular I think this design we have is flawed. >> It's goals are good but can be better achieved slightly >> differently. In particular the unshipped and shipped directory >> layout should be 'the same' but just differently rooted. Not in >> this release though. That let's $origin work better, among other >> advantages. Related and possibly solved same IMHO we don't >> adequately separate source and output - it should separate across >> multiple packages not just one at a time. But again, not on this >> release. >> >> - Jay (phone) >> >> On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" >> wrote: >> >>> I thought it might be helpful to highlight some of what I've >>> always understood as the design for the CM3 package system. So, I >>> pulled out my old documentation from Critical Mass as reference. >>> >>> I offer the following information to see if this discussion thread >>> concurs and/or wants to make any changes going forward, esp. as we >>> prepare for a new CM3 release. >>> >>> 1. CM3 takes care to separate source and derived files because >>> doing so (a) isolates source files for backup, revision control, >>> and searching; and (b) enables sharing the same source tree across >>> operating systems and architectures, without confusing object >>> files from different platforms. >>> >>> 2. Each package resides in a directory, with sources in a source >>> subdirectory ("src"), and generated files in a derived >>> subdirectory named to denote the platform on which the sources >>> were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. >>> >>> 3. Each developer can have multiple private packages, each stored >>> wherever desired in the filesystem. A private package named "foo" >>> would have the following filesystem structure: >>> +---foo >>> | +---src >>> | +---NT386 >>> | +---HPPA >>> | \---(...) >>> >>> 4. For each CM3 installation, there is one public package >>> repository that is available to all developers. When you ship a >>> [private] package, you make that package available to other >>> packages (and developers) via this public package repository. The >>> idea is that as a developer you would test your package in your >>> private repository before shipping it to the public repository. >>> (Sometimes m3overrides were needed when testing several related >>> private packages before shipping them.) >>> >>> 5. A typical CM3 installation is rooted at a given point in the >>> file system and contains the following folder structure: >>> CM3 >>> +---bin >>> +---doc >>> | +---help >>> | +---pics >>> | +---reference >>> | +---src_reports >>> | \---tutorial >>> +---examples >>> +---lib >>> +---pkg >>> | +---bitvector >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> | +---cm3ide >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> | +---(...) >>> | | +---src >>> | | +---NT386 >>> | | +---HPPA >>> | | \---(...) >>> >>> 6. In the past, the environment variable INSTALL_ROOT pointed to >>> the root of the CM3 tree in the file system. I think this >>> variable is ambiguously named and that we should change it to >>> CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 >>> installations (perhaps for different releases), one would simply >>> need to change the CM3_INSTALL_ROOT variable to point to the >>> desired installation for use at any particular point in time. For >>> this to work, all other variables cue off of CM3_INSTALL_ROOT. I >>> know that for the old cm3.cfg file, this was indeed the behavior. >>> Then, if someone had a special situation, they could override the >>> "cueing" behavior for any particular variable simply by changing >>> its definition on the fly. >>> >>> 7. Now, I also understand some (but not all) of what Jay is >>> saying about the library paths. Back in the old cm3 v4.1 days, I >>> had both HPPA and NT386 derived files for the same set of >>> sources. For Windows, the shipped exe and dll files went into the >>> public repository and you needed to have the CM3/bin folder on >>> your path. For private exe and dlls, you typically just ran them >>> out of the private package's derived NT386 folder. On HPPA, there >>> were some places in the file system that contained static >>> libraries and shared libraries, plus then you had the libraries >>> built using CM3. Again, the CM3 libraries went to the public >>> repository and there were environment variables to facilitate >>> finding the rest, including LD_LIBRARY_PATH. Now, from what Jay >>> is saying, the variety of operating environments seems to cloud up >>> all this. I know I'm a bit rusty wrt all the various unix >>> variants out there, but I recall that v4.1 worked out-of-the-box >>> for both NT386 and HPPA with respect to all this library path >>> stuff and I didn't have to make any symbolic links nor any hard >>> links to make it work. IMO, links are bad and too easily broken. >>> >>> 8. As for "build_standalone", I know there are various build/ >>> bootstrap reasons why some parts of CM3 had to be built this way. >>> But, for me, I've often used this feature for utility-type >>> programs to make it easier to distribute them. I can simply >>> distribute the one executable file without having to worry that >>> the target system might not have the right DLLs or the right >>> shared libraries in the right locations. For production code, >>> I've always built an installation program or an installation >>> script that installed all my executables and shared libraries in a >>> folder structure rooted at a particular point chosen by the end >>> user. Then, my programs always launched and used relative paths >>> from the install location to find everything they needed. >>> >>> Hope this info is helpful. >>> >>> Regards, >>> Randy Coleburn >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 03:36:16 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 2 Jul 2009 18:36:16 -0700 Subject: [M3devel] ROOT In-Reply-To: <4A4D0732.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> Message-ID: <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release. - Jay (phone) On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > I thought it might be helpful to highlight some of what I've always > understood as the design for the CM3 package system. So, I pulled > out my old documentation from Critical Mass as reference. > > I offer the following information to see if this discussion thread > concurs and/or wants to make any changes going forward, esp. as we > prepare for a new CM3 release. > > 1. CM3 takes care to separate source and derived files because > doing so (a) isolates source files for backup, revision control, and > searching; and (b) enables sharing the same source tree across > operating systems and architectures, without confusing object files > from different platforms. > > 2. Each package resides in a directory, with sources in a source > subdirectory ("src"), and generated files in a derived subdirectory > named to denote the platform on which the sources were built, e.g., > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > 3. Each developer can have multiple private packages, each stored > wherever desired in the filesystem. A private package named "foo" > would have the following filesystem structure: > +---foo > | +---src > | +---NT386 > | +---HPPA > | \---(...) > > 4. For each CM3 installation, there is one public package > repository that is available to all developers. When you ship a > [private] package, you make that package available to other packages > (and developers) via this public package repository. The idea is > that as a developer you would test your package in your private > repository before shipping it to the public repository. (Sometimes > m3overrides were needed when testing several related private > packages before shipping them.) > > 5. A typical CM3 installation is rooted at a given point in the > file system and contains the following folder structure: > CM3 > +---bin > +---doc > | +---help > | +---pics > | +---reference > | +---src_reports > | \---tutorial > +---examples > +---lib > +---pkg > | +---bitvector > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---cm3ide > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---(...) > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > > 6. In the past, the environment variable INSTALL_ROOT pointed to > the root of the CM3 tree in the file system. I think this variable > is ambiguously named and that we should change it to > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > installations (perhaps for different releases), one would simply > need to change the CM3_INSTALL_ROOT variable to point to the desired > installation for use at any particular point in time. For this to > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > for the old cm3.cfg file, this was indeed the behavior. Then, if > someone had a special situation, they could override the "cueing" > behavior for any particular variable simply by changing its > definition on the fly. > > 7. Now, I also understand some (but not all) of what Jay is saying > about the library paths. Back in the old cm3 v4.1 days, I had both > HPPA and NT386 derived files for the same set of sources. For > Windows, the shipped exe and dll files went into the public > repository and you needed to have the CM3/bin folder on your path. > For private exe and dlls, you typically just ran them out of the > private package's derived NT386 folder. On HPPA, there were some > places in the file system that contained static libraries and shared > libraries, plus then you had the libraries built using CM3. Again, > the CM3 libraries went to the public repository and there were > environment variables to facilitate finding the rest, including > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > operating environments seems to cloud up all this. I know I'm a bit > rusty wrt all the various unix variants out there, but I recall that > v4.1 worked out-of-the-box for both NT386 and HPPA with respect to > all this library path stuff and I didn't have to make any symbolic > links nor any hard links to make it work. IMO, links are bad and > too easily broken. > > 8. As for "build_standalone", I know there are various build/ > bootstrap reasons why some parts of CM3 had to be built this way. > But, for me, I've often used this feature for utility-type programs > to make it easier to distribute them. I can simply distribute the > one executable file without having to worry that the target system > might not have the right DLLs or the right shared libraries in the > right locations. For production code, I've always built an > installation program or an installation script that installed all my > executables and shared libraries in a folder structure rooted at a > particular point chosen by the end user. Then, my programs always > launched and used relative paths from the install location to find > everything they needed. > > Hope this info is helpful. > > Regards, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Fri Jul 3 08:40:27 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 3 Jul 2009 02:40:27 -0400 Subject: [M3devel] ROOT In-Reply-To: <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> Message-ID: <4A4D6F9A.1E75.00D7.1@scires.com> Jay: Not sure I fully appreciate/understand your last 3 posts below. I'd also like to hear what Tony and Olaf think about all this. Regards, Randy >>> 7/2/2009 9:57 PM >>> Ps this would also obsolete m3overrides, providing similar but better functionality, no need to encode the source structure in all those little extra files. - Jay (phone) On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: In particular I would argue that the directory layout should be made right at link time, into an alternate root. That alternate root possibly be prepopulated with links to or copies of the current good shared repository. Or the compiler should have notion of multiple roots to probe. However running the stuff implies hardlinks that are broken upon write. This scheme works better if source/interfaces are not needed in repository, just to cut down on the size. Are shipped source/interfaces used by compiler, or just the .m3exports/.m3x files? Anyway this is all thinking for a future release, not this year. 'ship' becomes just recursive copy or move.or change roots, plus maybe shipping source/interfaces too, kind of a wart. - Jay (phone) On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release. - Jay (phone) On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release. 1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms. 2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. 3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure: +---foo | +---src | +---NT386 | +---HPPA | \---(...) 4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) 5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure: CM3 +---bin +---doc | +---help | +---pics | +---reference | +---src_reports | \---tutorial +---examples +---lib +---pkg | +---bitvector | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---cm3ide | | +---src | | +---NT386 | | +---HPPA | | \---(...) | +---(...) | | +---src | | +---NT386 | | +---HPPA | | \---(...) 6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly. 7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken. 8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed. Hope this info is helpful. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From rcolebur at scires.com Fri Jul 3 08:42:50 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 3 Jul 2009 02:42:50 -0400 Subject: [M3devel] reminder about email replies to this list Message-ID: <4A4D702A.1E75.00D7.1@scires.com> I notice that I am getting two and three email messages containing the same text. I suspect that folks are just choosing to "reply all". Please note that you should really just reply to m3devel. That way we don't get multiple copies. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Fri Jul 3 11:22:05 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 11:22:05 +0200 Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT In-Reply-To: <4A4D6F9A.1E75.00D7.1@scires.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> <4A4D6F9A.1E75.00D7.1@scires.com> Message-ID: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> Quoting Randy Coleburn : > Jay: > > Not sure I fully appreciate/understand your last 3 posts below. > > I'd also like to hear what Tony and Olaf think about all this. I think Jay chiefly opts for a long unimplemented wish of mine: a hierarchy of repositories that is searched by the M3 builder. Imagine that you can have one global repository, which contains some standard and base packages and tools, and several project repositories, each of which is used by teams whose members all have private repositories for their own test and development purposes. A note on terminology: I don't really like to use the term `repository' here, as it is usually used in connection with version control systems. In ComPact, a tool developed and used years ago by Elego, we called these `repositories' which contained pre-built packages `package pools' or just `pools'. So I'll use that term instead of repository from now on. The CM3 builder needs to be extended to search a set of pools instead of just one (INSTALL_ROOT). This could be expressed by a CM3_POOL_PATH, similar to the Java class path: CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 To satisfy package imports, the builder would start searching in the first pool and continue until it has found an appropriate package. This way local or project changes could easily be tested and integrated before being `promoted' to a higher level. For backward compatibility reasons, there should be a default pool (/usr/local/cm3) which is used when nothing else is defined. Shipping of packages would by default use the first pool found in the CM3_POOL_PATH. The second extension needed would be the `promote' operation, which ships a package from one pool to another pool. Of course CM3 would need to make sure that all dependencies are correct and the shipped package does actually work within the new context (the destination pool's packages). If the package structure is the same in the workspace and in package pools, standard shipping and promoting operations would just be file copies (after appropriate correctness checks) as Jay says. Also, as Jay noticed, the `hack' of m3overrides wouldn't be necessary any more. I don't think this would be too difficult to implement. I just haven't found the time to do it yet ;-) Some further remarks to topics touched below: Shared libraries weren't in wide-spread use when the M3 package systme was designed. Only few of the DEC SRC targets actually contained support for them. IMO it's OK to ship them all to one directory, but to make things work for multi-architecture pools, we'd need to distinguish the library and binary paths there, too. So we'd have something like root/pkg/pkg-a/src /NT386 /I386_DARWIN /pkg-b/src /NT386 /I386_DARWIN /man /bin/NT386 /I386_DARWIN ... /lib/NT386 /I386_DARWIN ... Symbolic links were used for dynamic libraries by the related quake code as long as I remember. The variable ROOT is legacy, I think it was used for overrides even by DEC SRC. I've got no objection to rename it, but, as described above, we should rather make it vanish. Olaf > Regards, > Randy > >>>> 7/2/2009 9:57 PM >>> > > Ps this would also obsolete m3overrides, providing similar but > better functionality, no need to encode the source structure in all > those little extra files. > > - Jay (phone) > > On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > > > In particular I would argue that the directory layout should be made > right at link time, into an alternate root. That alternate root > possibly be prepopulated with links to or copies of the current good > shared repository. Or the compiler should have notion of multiple > roots to probe. However running the stuff implies hardlinks that are > broken upon write. This scheme works better if source/interfaces > are not needed in repository, just to cut down on the size. Are > shipped source/interfaces used by compiler, or just the > .m3exports/.m3x files? Anyway this is all thinking for a future > release, not this year. 'ship' becomes just recursive copy or > move.or change roots, plus maybe shipping source/interfaces too, > kind of a wart. > > - Jay (phone) > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > > > The system used/uses symlinks under the covers. I don't think cm3 > historically supported shared libs on hpux probably because the > bundled compiler does not. Granted my exposure to hpux is only in > recent times. 'standalone' as you define is useful but I think that > reason isn't applicable to anything 'within cm3 itself'. Maybe more > to say later. In particular I think this design we have is flawed. > It's goals are good but can be better achieved slightly differently. > In particular the unshipped and shipped directory layout should be > 'the same' but just differently rooted. Not in this release though. > That let's $origin work better, among other advantages. Related and > possibly solved same IMHO we don't adequately separate source and > output - it should separate across multiple packages not just one at > a time. But again, not on this release. > > - Jay (phone) > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > > > I thought it might be helpful to highlight some of what I've always > understood as the design for the CM3 package system. So, I pulled > out my old documentation from Critical Mass as reference. > > I offer the following information to see if this discussion thread > concurs and/or wants to make any changes going forward, esp. as we > prepare for a new CM3 release. > > 1. CM3 takes care to separate source and derived files because > doing so (a) isolates source files for backup, revision control, and > searching; and (b) enables sharing the same source tree across > operating systems and architectures, without confusing object files > from different platforms. > > 2. Each package resides in a directory, with sources in a source > subdirectory ("src"), and generated files in a derived subdirectory > named to denote the platform on which the sources were built, e.g., > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > 3. Each developer can have multiple private packages, each stored > wherever desired in the filesystem. A private package named "foo" > would have the following filesystem structure: > +---foo > | +---src > | +---NT386 > | +---HPPA > | \---(...) > > 4. For each CM3 installation, there is one public package > repository that is available to all developers. When you ship a > [private] package, you make that package available to other packages > (and developers) via this public package repository. The idea is > that as a developer you would test your package in your private > repository before shipping it to the public repository. (Sometimes > m3overrides were needed when testing several related private > packages before shipping them.) > > 5. A typical CM3 installation is rooted at a given point in the > file system and contains the following folder structure: > CM3 > +---bin > +---doc > | +---help > | +---pics > | +---reference > | +---src_reports > | \---tutorial > +---examples > +---lib > +---pkg > | +---bitvector > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---cm3ide > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > | +---(...) > | | +---src > | | +---NT386 > | | +---HPPA > | | \---(...) > > 6. In the past, the environment variable INSTALL_ROOT pointed to > the root of the CM3 tree in the file system. I think this variable > is ambiguously named and that we should change it to > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > installations (perhaps for different releases), one would simply > need to change the CM3_INSTALL_ROOT variable to point to the desired > installation for use at any particular point in time. For this to > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > for the old cm3.cfg file, this was indeed the behavior. Then, if > someone had a special situation, they could override the "cueing" > behavior for any particular variable simply by changing its > definition on the fly. > > 7. Now, I also understand some (but not all) of what Jay is saying > about the library paths. Back in the old cm3 v4.1 days, I had both > HPPA and NT386 derived files for the same set of sources. For > Windows, the shipped exe and dll files went into the public > repository and you needed to have the CM3/bin folder on your path. > For private exe and dlls, you typically just ran them out of the > private package's derived NT386 folder. On HPPA, there were some > places in the file system that contained static libraries and shared > libraries, plus then you had the libraries built using CM3. Again, > the CM3 libraries went to the public repository and there were > environment variables to facilitate finding the rest, including > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > operating environments seems to cloud up all this. I know I'm a bit > rusty wrt all the various unix variants out there, but I recall > that v4.1 worked out-of-the-box for both NT386 and HPPA with > respect to all this library path stuff and I didn't have to make > any symbolic links nor any hard links to make it work. IMO, links > are bad and too easily broken. > > 8. As for "build_standalone", I know there are various > build/bootstrap reasons why some parts of CM3 had to be built this > way. But, for me, I've often used this feature for utility-type > programs to make it easier to distribute them. I can simply > distribute the one executable file without having to worry that the > target system might not have the right DLLs or the right shared > libraries in the right locations. For production code, I've always > built an installation program or an installation script that > installed all my executables and shared libraries in a folder > structure rooted at a particular point chosen by the end user. > Then, my programs always launched and used relative paths from the > install location to find everything they needed. > > Hope this info is helpful. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 3 13:25:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 11:25:28 +0000 Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT In-Reply-To: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> References: <680C9B05-FAEB-43E7-8B38-107DA6A847CD@cs.purdue.edu> <6CEC16FF-9287-4755-B84F-DACE9A848872@hotmail.com> <4A4CC4CE.1E75.00D7.1@scires.com> <1DDBB148-0F84-418E-9289-44FD5ED3C936@cs.purdue.edu> <4A4D0732.1E75.00D7.1@scires.com> <31470B74-19DD-4204-92B5-E5B01B903987@hotmail.com> <90CFAD72-D478-4BAF-BF37-6A63E582E3C2@hotmail.com> <8BC862F6-1092-4296-B811-E8D154806672@hotmail.com> <4A4D6F9A.1E75.00D7.1@scires.com> <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com> Message-ID: [didn't really finish editing this..ran out of energe..] Cool. > For backward compatibility reasons, there should be a default pool > (/usr/local/cm3) which is used when nothing else is defined. "I THINK:" (ie: I'm not sure, winging it..) The last pool searched would correspond to where the compiler is. The first one might be ROOT/pkg. I'd kind of like it to be outside ROOT entirely, but having it be one toplevel directory in ROOT is progress. ? An initial version that only supports two pools doesn't rqeuire another setting. ? You know, do-cm3-all realclean would be rm -rf firstpool and optionally "clone" or "populate" firstpool from secondpool. Clone/populate might be separate step, such as if I'm cleaning now, but not building till later. ? A system with multiple pools requires more thought than just two pools. Like, well, you need more parameters. In a two pool system, promote is always from "private" to "public". In a multi pool system, you need to specify earlier pool and later pool, and all the "in between" pools need to be updated as well, or possibly deleted. Actually a multi pool system..I'm not sure this works well. In particular because of $origin. In particular because the search for shared libraries doesn't necessarily follow analogously to cm3's search for packages. Well, ok, I admit, what probably works well is CM3_POOLs=pool1;pool2;pool3 LD_LIBRARY_PATH=pool1/lib;pool2/lib:pool3/lib Then you can have an arbitrary number of pools and they can all be sparse and you can imagine promoting just a package at a time. If you use $origin, pool/lib can't be sparse. Perhaps just pool/lib, but all the rest can be sparse. Do you promote packages or pools? I think you actually promote entire pools. Aha, see, this solves another problem. This solves cm3 being dynamically linked. Because you promote an entire pool at a time, multiple packages simultaneously, you don't have a new cm3 using an old m3core, because you would build both before any promote. This also fixes the problem where cm3 can't ship itself, because, something like, you never run anything in the first pool. (Similarly it removes the need to build things build_standalone because they run "unshipped". In fact, it makes it so runpath is just $origin/../lib is ok, it removes the problem of unshipped binaries living in a directory layout vs. shipped binaries). That defers to the problem. cm3 might be unable to promote itself. However, first of all, one many systems even NT you can rename and replace. Subsequent invocations can look for and delete the renamed copies. Also, promote might be a wrapper .sh/.cmd, runs the executable, which does most of the work, and leaves behind another .sh/.cmd for the wrapper to run as its last step. Any build output that is "shipped" today would instead be written to the first pool. Non-shipped build outputs, not sure. .o/.mo/.io files. There would probably be another "root" to indicated where unshipped outputs go. That way the entire source tree is kept clean, not just individual packages. > IMO it's OK to ship them all to one directory, but to make things > work for multi-architecture pools, we'd need to distinguish the > library and binary paths there, too. So we'd have something like This is a long-standing dilemna of mine. If multi-architecture pools are the goal, or you just use different roots. Or at least if you have multi-architecture host pools, or only multi-targets. Specifically, bin and lib historically lack architecture, while pkg has it. This should suffice for such a pool to target multiple architectures but not host on multiple architectures. I've long though that maybe root/bin should only contain .cmd/.py/.sh files that determine their host architecture and then run root/pkg/foo/target/foo. Note that this breaks $origin. You could use root/bin/target/foo, root/lib/target/foo and $origin/../../lib but I worry when there are too many ".." in $origin, you run the risk of "escaping" away from "your files" and out into whatever is in the file system. This is a constant dilemna for me because I mostly use a host that supports three Modula-3 hosts. My installation is at c:\cm3 and sometimes c:\cm3\bin\cm3.exe is Cygwin, sometimes it is NT386, and Interix uses c:\cm3\bin\cm3 with no extension. I don't have a clean workflow here. Either I should have c:\cm3 (native), c:\cm3.cygwin, c:\cm3.interix, or I should have c:\cm3\bin\nt386\cm3, c:\cm3\bin\cygwin\cm3, c:\cm3\bin\interix\cm3, or somesuch. Again, though, $origin is a factor here. c:\cm3.cygwin et. al. requires no changes and no concert wrt $origin. Olaf below advocates something more like c:\cm3\bin\nt386\cm3 and I don't disagree, I'm just not sure. "Repository" has many uses. It is "a place you put things". Often it is more like "well structured part of the file system", or deliberately structured. A pool is more like "a collection from which to draw stuff". - Jay > Date: Fri, 3 Jul 2009 11:22:05 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Some comments about package structure and package pools, was: Re: ROOT > > Quoting Randy Coleburn : > > > Jay: > > > > Not sure I fully appreciate/understand your last 3 posts below. > > > > I'd also like to hear what Tony and Olaf think about all this. > > I think Jay chiefly opts for a long unimplemented wish of mine: > a hierarchy of repositories that is searched by the M3 builder. > Imagine that you can have one global repository, which contains > some standard and base packages and tools, and several project > repositories, each of which is used by teams whose members all have > private repositories for their own test and development purposes. > > A note on terminology: I don't really like to use the term > `repository' here, as it is usually used in connection with version > control systems. In ComPact, a tool developed and used years ago by > Elego, we called these `repositories' which contained pre-built packages > `package pools' or just `pools'. So I'll use that term instead of > repository from now on. > > The CM3 builder needs to be extended to search a set of pools > instead of just one (INSTALL_ROOT). This could be expressed by > a CM3_POOL_PATH, similar to the Java class path: > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 > > To satisfy package imports, the builder would start searching in the > first pool and continue until it has found an appropriate package. > This way local or project changes could easily be tested and integrated > before being `promoted' to a higher level. > > For backward compatibility reasons, there should be a default pool > (/usr/local/cm3) which is used when nothing else is defined. > > Shipping of packages would by default use the first pool found in the > CM3_POOL_PATH. > > The second extension needed would be the `promote' operation, which > ships a package from one pool to another pool. Of course CM3 would > need to make sure that all dependencies are correct and the shipped > package does actually work within the new context (the destination > pool's packages). > > If the package structure is the same in the workspace and in package > pools, standard shipping and promoting operations would just be > file copies (after appropriate correctness checks) as Jay says. > > Also, as Jay noticed, the `hack' of m3overrides wouldn't be > necessary any more. > > I don't think this would be too difficult to implement. I just haven't > found the time to do it yet ;-) > > Some further remarks to topics touched below: > > Shared libraries weren't in wide-spread use when the M3 package > systme was designed. Only few of the DEC SRC targets actually > contained support for them. > > IMO it's OK to ship them all to one directory, but to make things > work for multi-architecture pools, we'd need to distinguish the > library and binary paths there, too. So we'd have something like > > root/pkg/pkg-a/src > /NT386 > /I386_DARWIN > /pkg-b/src > /NT386 > /I386_DARWIN > /man > /bin/NT386 > /I386_DARWIN > ... > /lib/NT386 > /I386_DARWIN > ... > > Symbolic links were used for dynamic libraries by the related quake > code as long as I remember. > > The variable ROOT is legacy, I think it was used for overrides even > by DEC SRC. I've got no objection to rename it, but, as described above, > we should rather make it vanish. > > Olaf > > > Regards, > > Randy > > > >>>> 7/2/2009 9:57 PM >>> > > > > Ps this would also obsolete m3overrides, providing similar but > > better functionality, no need to encode the source structure in all > > those little extra files. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 6:50 PM, jayk123 at hotmail.com wrote: > > > > > > In particular I would argue that the directory layout should be made > > right at link time, into an alternate root. That alternate root > > possibly be prepopulated with links to or copies of the current good > > shared repository. Or the compiler should have notion of multiple > > roots to probe. However running the stuff implies hardlinks that are > > broken upon write. This scheme works better if source/interfaces > > are not needed in repository, just to cut down on the size. Are > > shipped source/interfaces used by compiler, or just the > > .m3exports/.m3x files? Anyway this is all thinking for a future > > release, not this year. 'ship' becomes just recursive copy or > > move.or change roots, plus maybe shipping source/interfaces too, > > kind of a wart. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 6:36 PM, jayk123 at hotmail.com wrote: > > > > > > The system used/uses symlinks under the covers. I don't think cm3 > > historically supported shared libs on hpux probably because the > > bundled compiler does not. Granted my exposure to hpux is only in > > recent times. 'standalone' as you define is useful but I think that > > reason isn't applicable to anything 'within cm3 itself'. Maybe more > > to say later. In particular I think this design we have is flawed. > > It's goals are good but can be better achieved slightly differently. > > In particular the unshipped and shipped directory layout should be > > 'the same' but just differently rooted. Not in this release though. > > That let's $origin work better, among other advantages. Related and > > possibly solved same IMHO we don't adequately separate source and > > output - it should separate across multiple packages not just one at > > a time. But again, not on this release. > > > > - Jay (phone) > > > > On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" wrote: > > > > > > I thought it might be helpful to highlight some of what I've always > > understood as the design for the CM3 package system. So, I pulled > > out my old documentation from Critical Mass as reference. > > > > I offer the following information to see if this discussion thread > > concurs and/or wants to make any changes going forward, esp. as we > > prepare for a new CM3 release. > > > > 1. CM3 takes care to separate source and derived files because > > doing so (a) isolates source files for backup, revision control, and > > searching; and (b) enables sharing the same source tree across > > operating systems and architectures, without confusing object files > > from different platforms. > > > > 2. Each package resides in a directory, with sources in a source > > subdirectory ("src"), and generated files in a derived subdirectory > > named to denote the platform on which the sources were built, e.g., > > "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc. > > > > 3. Each developer can have multiple private packages, each stored > > wherever desired in the filesystem. A private package named "foo" > > would have the following filesystem structure: > > +---foo > > | +---src > > | +---NT386 > > | +---HPPA > > | \---(...) > > > > 4. For each CM3 installation, there is one public package > > repository that is available to all developers. When you ship a > > [private] package, you make that package available to other packages > > (and developers) via this public package repository. The idea is > > that as a developer you would test your package in your private > > repository before shipping it to the public repository. (Sometimes > > m3overrides were needed when testing several related private > > packages before shipping them.) > > > > 5. A typical CM3 installation is rooted at a given point in the > > file system and contains the following folder structure: > > CM3 > > +---bin > > +---doc > > | +---help > > | +---pics > > | +---reference > > | +---src_reports > > | \---tutorial > > +---examples > > +---lib > > +---pkg > > | +---bitvector > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > | +---cm3ide > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > | +---(...) > > | | +---src > > | | +---NT386 > > | | +---HPPA > > | | \---(...) > > > > 6. In the past, the environment variable INSTALL_ROOT pointed to > > the root of the CM3 tree in the file system. I think this variable > > is ambiguously named and that we should change it to > > CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 > > installations (perhaps for different releases), one would simply > > need to change the CM3_INSTALL_ROOT variable to point to the desired > > installation for use at any particular point in time. For this to > > work, all other variables cue off of CM3_INSTALL_ROOT. I know that > > for the old cm3.cfg file, this was indeed the behavior. Then, if > > someone had a special situation, they could override the "cueing" > > behavior for any particular variable simply by changing its > > definition on the fly. > > > > 7. Now, I also understand some (but not all) of what Jay is saying > > about the library paths. Back in the old cm3 v4.1 days, I had both > > HPPA and NT386 derived files for the same set of sources. For > > Windows, the shipped exe and dll files went into the public > > repository and you needed to have the CM3/bin folder on your path. > > For private exe and dlls, you typically just ran them out of the > > private package's derived NT386 folder. On HPPA, there were some > > places in the file system that contained static libraries and shared > > libraries, plus then you had the libraries built using CM3. Again, > > the CM3 libraries went to the public repository and there were > > environment variables to facilitate finding the rest, including > > LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of > > operating environments seems to cloud up all this. I know I'm a bit > > rusty wrt all the various unix variants out there, but I recall > > that v4.1 worked out-of-the-box for both NT386 and HPPA with > > respect to all this library path stuff and I didn't have to make > > any symbolic links nor any hard links to make it work. IMO, links > > are bad and too easily broken. > > > > 8. As for "build_standalone", I know there are various > > build/bootstrap reasons why some parts of CM3 had to be built this > > way. But, for me, I've often used this feature for utility-type > > programs to make it easier to distribute them. I can simply > > distribute the one executable file without having to worry that the > > target system might not have the right DLLs or the right shared > > libraries in the right locations. For production code, I've always > > built an installation program or an installation script that > > installed all my executables and shared libraries in a folder > > structure rooted at a particular point chosen by the end user. > > Then, my programs always launched and used relative paths from the > > install location to find everything they needed. > > > > Hope this info is helpful. > > > > Regards, > > Randy Coleburn > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 15:46:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 13:46:24 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 15:53:29 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 13:53:29 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 16:19:02 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 14:19:02 +0000 Subject: [M3devel] FW: removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [trying again...truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 3 18:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Jul 2009 16:14:43 +0000 Subject: [M3devel] removal of recent hardlink usage (using lib and not pkg) In-Reply-To: <20090703133757.41972CC802@birch.elegosoft.com> References: <20090703133757.41972CC802@birch.elegosoft.com> Message-ID: [trying again again...truncated] From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: re: removal of recent hardlink usage (using lib and not pkg) Date: Fri, 3 Jul 2009 13:46:24 +0000 Easier than I thought. See, I kinda though install_derived was more important and should be used. But just replace it with LibdExport. Index: AMD64_DARWIN =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN,v retrieving revision 1.5 diff -u -r1.5 AMD64_DARWIN --- AMD64_DARWIN 29 Jun 2009 18:52:01 -0000 1.5 +++ AMD64_DARWIN 3 Jul 2009 13:37:03 -0000 @@ -321,18 +321,21 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end @@ -355,18 +358,21 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Darwin.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common,v retrieving revision 1.9 diff -u -r1.9 Darwin.common --- Darwin.common 29 Jun 2009 18:52:01 -0000 1.9 +++ Darwin.common 3 Jul 2009 13:37:03 -0000 @@ -138,18 +138,20 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -172,18 +174,22 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived (lib_soxx) - install_derived_link (lib_soxx, lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_soxx, LIB_INSTALL) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_soxx) + link_file(lib_soxx, LIB_INSTALL & SL & lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) + else delete_file (lib_so) delete_file (lib_sox) delete_file (lib_soxx) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + delete_file(pkg & lib_soxx) + return 0 end Index: Solaris.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Solaris.common,v retrieving revision 1.12 diff -u -r1.12 Solaris.common --- Solaris.common 29 Jun 2009 18:52:01 -0000 1.12 +++ Solaris.common 3 Jul 2009 13:37:03 -0000 @@ -85,15 +85,18 @@ link_file(lib_sox, lib_so) % finally, make sure the shared library stuff gets installed properly - install_derived (lib_sox) - install_derived_link (lib_sox, lib_so) - install_link_to_derived (lib_sox, LIB_INSTALL) - install_link_to_derived (lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) else delete_file (lib_so) delete_file (lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.29 diff -u -r1.29 Unix.common --- Unix.common 27 Jun 2009 16:53:43 -0000 1.29 +++ Unix.common 3 Jul 2009 13:37:03 -0000 @@ -311,12 +311,15 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end @@ -342,16 +345,19 @@ link_file(lib_sox, lib_so) % make sure the shared library stuff gets installed properly - install_derived(lib_sox) - install_derived_link(lib_sox, lib_so) - install_hard_link_to_derived(lib_sox, LIB_INSTALL) - install_link_to_derived(lib_so, LIB_INSTALL) + LibdExport(lib_sox) + link_file(lib_sox, LIB_INSTALL & SL & lib_so) ShipM3CoreStaticObjs(lib) else delete_file(lib_so) delete_file(lib_sox) end + % delete old .so files in package store + local pkg = PKG_INSTALL & SL & lib & SL & TARGET & SL + delete_file(pkg & lib_so) + delete_file(pkg & lib_sox) + return 0 end Index: cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.27 diff -u -r1.27 cm3cfg.common --- cm3cfg.common 18 Jun 2009 16:20:48 -0000 1.27 +++ cm3cfg.common 3 Jul 2009 13:37:03 -0000 @@ -105,14 +105,6 @@ %------------------------------------------------------------------------------ -if not defined("install_hard_link_to_derived") - proc install_hard_link_to_derived(a, b) is - install_link_to_derived(a, b) - end -end - -%------------------------------------------------------------------------------ - if not defined("subst_chars") % % Ok, some cross builds will fail with older tools, but > Date: Fri, 3 Jul 2009 15:37:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/07/03 15:37:57 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: AMD64_DARWIN > Darwin.common > Solaris.common > Unix.common > cm3cfg.common > > Log message: > Put .so/.dylib files only in root/lib and not in root/pkg. > Delete any that are leftover in root/pkg. > Despite the multiple platform-specific implementations, > tested only on AMD64_LINUX. Solaris, Darwin, subject to > breakage due to typos, etc., but it should be at least > close to correct. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 3 19:44:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 3 Jul 2009 13:44:34 -0400 Subject: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc. In-Reply-To: References: <1C32FCD7-BB28-492E-8D49-4B4EBBB891C1@hotmail.com> <0810F57D-463E-41BD-9BBD-AD65C84DD796@cs.purdue.edu> <20090702200436.ijbbx6pxcww8kgs4@mail.elegosoft.com> <43326BF0-E990-4849-A312-5144D5B0C966@cs.purdue.edu> <358E750A-E838-43F0-BDDE-E819A0B1E1D9@cs.purdue.edu> Message-ID: On 2 Jul 2009, at 16:23, Jay wrote: > (I just didn't like the link stuff and I still don't understand > what ROOT is there for). > > The point was to add Unix.link where it belongs, m3core, and use it > from where can't depend on new m3core. > And maybe go overboard in sharing the source, to a trivial one > line function (less trivial on Win32, in order to support pre- > Win2000 OS). > The point was to put the files in lib and also leave them in pkg, > without wasting space. > The decision now, which I still have to try, is to stop putting the > files in pkg, so then no hardlink needed. Sounds good. > $origin vs. full paths is still debatable and I still convinced > $origin is the way to go. I agree $origin is best way to go. > I'm also inclined to put $origin and $origin/../lib in rpath, so > backups can flatten the structure to just one directory: > /backup/cm3 > /backup/libm3core.so > /backup/libm3.so Fair enough. > in some /hypothetical future/ where cm3 is dynamically linked. > As long there are no "duplicates" -- files in both bin and lib, the > runpath remains fairly clear/unambiguous. > And even then, the order is pretty clearly left to right.. Not sure I understand. > > - Jay > > > > > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 16:17:54 -0400 > > On 2 Jul 2009, at 16:03, Jay wrote: > > Ok, so I think a very important question is: > > >>> Should users have a choice of where to install? > > Yes! > > >>> What are the reasonable ramifications of someone who makes a > non-default choice? > > /Personally/ I want the choice, esp. if I don't have root access!, > and I don't want to set LD_LIBRARY_PATH. > I want my choice and no negative consequences, and $origin basically > gives me that. > Except NetBSD prior to 5.0. 5.0 already released. > And I guess Solaris prior to 2.7 or such. > > > We do agree on a change vs. previous releases, at least. > And it overlaps with what I did already. > > I think so. (I just didn't like the link stuff and I still don't > understand what ROOT is there for). > > > > > - Jay > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, > symlinks, hardlinks, etc. > Date: Thu, 2 Jul 2009 15:59:25 -0400 > > I agree, LD_LIBRARY_PATH should only be used by power-users in a > pinch during development. > > On 2 Jul 2009, at 14:56, Jay wrote: > Here are some good links, other people trying to explain this stuff: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 3 21:36:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 21:36:42 +0200 Subject: [M3devel] building m3gdb on AMD64_LINUX Message-ID: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> building m3gdb on birch ends with gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/tui/tui-winsource.c /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c c-exp.c.tmp -- yacc Cannot open "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" make[2]: *** [c-exp.c] Error 1 make[2]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' make[1]: *** [all-gdb] Error 2 make[1]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' make: *** [all] Error 2 "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile 4 /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args Fatal Error: package build failed Any hints? Wrong yacc? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 3 21:38:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Jul 2009 21:38:54 +0200 Subject: [M3devel] some testing of the new web pages In-Reply-To: References: Message-ID: <20090703213854.76mnwfvjms0w804c@mail.elegosoft.com> Quoting Jay : > I do like the new web pages. > Here are some problems though. Most of the problems below should be fixed now. I've removed packages tcl, mtex and PEX from the distribution, since I don't think they will be useful in their current form. Regards, Olaf > http://www.opencm3.net/releng/collection-core.html > > > go down to m3-sys/cm3 > the builder and freebsd manual page links aren't right. > I think these are maybe just CVS merge conflicts > that happen to be on the packaging machine and > can just be deleted. > > Not clear if most of the gcc links are useful. > > > go down to TCL interfaces for M3 > The browse sources link doesn't work. > Probably related to this not always building and not built. > Probably need to modify this and require people doing package building > to have Tcl installed, maybe even for NT386. > Probably specifically make-dist.sh should set $ENABLE_TCL or somesuch. > (not exactly) > > > The source links present, e.g. the licenses oddly, > but compactly and probably a good thing, e.g.: > http://www.opencm3.net/doc/help/gen_html/tcp/src/common/StreamRdClass.m3.html > Probably an artifact of m3tohtml. > > > http://www.opencm3.net/releng > Go down the righthand side trying everything to one level. > Broken: > http://www.opencm3.net/releng/collection-min.html > http://www.opencm3.net/releng/collection-caltech.html > > > But there is: > http://www.opencm3.net/releng/collection-caltech-parser.html > It contains m3-win/import-libs but shouldn't. > > > I suspect the problems are rooted in: > min is a non-ws package set but not a ws package set. > Because it is overlys small and core subsumes it? > caltech-parser contains a dash. > min to me is specifically enough to start with an old release and > build a current compiler and release -- m3core, libm3, m3cg, cm3, > maybe sysutils > specifically it is the pieces required to compile anything (cm3, m3cg) > and the pieces that an old compiler may not be able to build the > the current versions of (m3core/libm3) that a current compiler will need; > That is, if you want to build natively build the whole system from source, > this is the smallest you can start with. m3cg actually isn't in min but > probably handled specially. > > > Related couments usually but not always > has one extra empty bullet, including but not limited > to when the list is empty: > > http://www.opencm3.net/releng/collection-cvsup.html > http://www.opencm3.net/releng/collection-anim.html > http://www.opencm3.net/releng/collection-cvsup.html > http://www.opencm3.net/releng/collection-database.html > http://www.opencm3.net/releng/collection-demo.html > http://www.opencm3.net/releng/collection-devlib.html > http://www.opencm3.net/releng/collection-game.html > http://www.opencm3.net/releng/collection-gui.html > > This is not all the ones with an extra bullet, and a few > don't have the extra bullet. > > I'm on the fence on the whole ws thing. > Non-ws also has matching source. > The point is to provide the packages both built > and buildable? > If cm3 had a mode that started with assemble then link and ship, > we could cross build all the ws packages, very nice. > > I guess the "real" problem is I feel compelled then to > match this feature in make-dist.py. > > http://www.opencm3.net/releng/collection-tool.html > Try the first few links. > mtex > Browse sources seems incomplete but maybe is right. > The man page links are all broken. > > cmpdir > shows a general pattern: > maybe directories with no files shouldn't be shown? > > http://www.opencm3.net/releng/collection-demo.html > fisheye > The link manual page .makefile isn't right > > > http://www.opencm3.net/releng/collection-devlib.html > m3tk > Several broken manpage links. > > pex > browse sources doesn't work > Probably like Tcl, not always built. > > > http://www.opencm3.net/releng/collection-anim.html > zeus > contains a broken Zeus manual page, I think a CVS conflict file > Might be able to search for this generally in the html. > > http://www.opencm3.net/releng/collection-obliq.html > related documents > first link, to polymtl, broken, sounds promising, maybe > we can find it and host it > > http://www.opencm3.net/releng/collection-m3gdb.html > m3gdb > Like m3cc, maybe some of these READMEs not useful. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Fri Jul 3 23:53:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 03 Jul 2009 16:53:31 -0500 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> Message-ID: <4A4E7DDB.2090107@cox.net> On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc is circuitously symlinked to a script that executes /usr/bin/bison -y. In any case, usually, there is no need to execute yacc when building (m3)gdb, because its output is already present and newer than yacc's input, in this case, c-exp.y. I think this is the way it is in the CVS repository. Did some dates in your source copy get touched? I have no idea where the c-exp.t file it wants is supposed to come from. In a brief look, I didn't find any reference to a *.t file at all, either in the script m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the bison man page on my machine). Maybe original yacc does something with it. I would have thought ylwrap would have been written to work with a number of varieties of yacc and equivalents. Do you have a copy of c-exp.y? I suspect having a newer c-exp.c than c-exp.y will circumvent this problem, but of course we probably want it set up to work when c-exp.c needs to be rebuilt. Olaf Wagner wrote: > building m3gdb on birch ends with > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > -Wformat-nonliteral -Wunused-label -Wunused-function > ../../gdb/gdb/tui/tui-winsource.c > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > c-exp.c.tmp -- yacc > Cannot open > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > make[2]: *** [c-exp.c] Error 1 > make[2]: Leaving directory > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > make[1]: *** [all-gdb] Error 2 > make[1]: Leaving directory > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > make: *** [all] Error 2 > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > --procedure-- -line- -file--- > exec -- > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > 4 > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > Any hints? Wrong yacc? > > Olaf From hendrik at topoi.pooq.com Sat Jul 4 01:12:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Jul 2009 19:12:54 -0400 Subject: [M3devel] multiarch Message-ID: <20090703231254.GA25415@topoi.pooq.com> It seems relevant to out multiarchitecture system that Debian and Ubuntu are currently also struggling to put together a multiarchitecture system. Current thinking seems to be posted at https://wiki.ubuntu.com/MultiarchSpec The stimulus for this work seems to be having 32-bit and 64-bit programs coexist on the same AMD-64 system. But it also deals with questions like MIPS systems having at least three different ABIs. Have a look. -- hendrik From hendrik at topoi.pooq.com Sat Jul 4 01:15:09 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Jul 2009 19:15:09 -0400 Subject: [M3devel] multiarch In-Reply-To: <20090703231254.GA25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> Message-ID: <20090703231509.GB25415@topoi.pooq.com> On Fri, Jul 03, 2009 at 07:12:54PM -0400, hendrik at topoi.pooq.com wrote: > > The stimulus for this work seems to be having 32-bit and 64-bit programs > coexist on the same AMD-64 system. But it also deals with questions > like MIPS systems having at least three different ABIs. They're also considering interpreters like Python to be architectures to be supported. -- hendrik From jay.krell at cornell.edu Sat Jul 4 08:48:19 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 06:48:19 +0000 Subject: [M3devel] multiarch In-Reply-To: <20090703231509.GB25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> Message-ID: The Python thing as I understand it, is that sometimes package foo depends on package bar, and they must be of the same architecture, and sometimes not. Specifically inproc "plugins" require matching architecture, but if I just run an executable, architecture doesn't usually have to match. OpenBSD sets an interesting counterexample -- no biarch/multiarch, just one architecture, "same as it ever was", "no additional complexity", "everything is built from source anyway". - Jay > Date: Fri, 3 Jul 2009 19:15:09 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiarch > > On Fri, Jul 03, 2009 at 07:12:54PM -0400, hendrik at topoi.pooq.com wrote: > > > > The stimulus for this work seems to be having 32-bit and 64-bit programs > > coexist on the same AMD-64 system. But it also deals with questions > > like MIPS systems having at least three different ABIs. > > They're also considering interpreters like Python to be architectures to > be supported. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:28:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <4A4E7DDB.2090107@cox.net> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:33:48 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:33:48 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: It built ok for me a second time. The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb. yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means. You might just try rm -rf m3gdb and cvs -z3 upd -dAP. Maybe there is/was a timestamp problem. As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: Re: [M3devel] building m3gdb on AMD64_LINUX It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 4 17:35:51 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 15:35:51 +0000 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: See also C:\dev2\cm3.2\caltech-parser\parserlib\klex\src From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Subject: RE: [M3devel] building m3gdb on AMD64_LINUX Date: Sat, 4 Jul 2009 15:33:48 +0000 It built ok for me a second time. The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb. yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means. You might just try rm -rf m3gdb and cvs -z3 upd -dAP. Maybe there is/was a timestamp problem. As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at cox.net; m3devel at elegosoft.com Date: Sat, 4 Jul 2009 15:28:24 +0000 Subject: Re: [M3devel] building m3gdb on AMD64_LINUX It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc. I'm investigating more, but maybe not right now. - Jay > Date: Fri, 3 Jul 2009 16:53:31 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building > (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did some > dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. > I would have thought ylwrap would have been written to work with a number > of varieties of yacc and equivalents. > > Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to be > rebuilt. > > Olaf Wagner wrote: > > building m3gdb on birch ends with > > > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config > > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. > > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl > > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type > > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith > > -Wformat-nonliteral -Wunused-label -Wunused-function > > ../../gdb/gdb/tui/tui-winsource.c > > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c > > c-exp.c.tmp -- yacc > > Cannot open > > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" > > > > make[2]: *** [c-exp.c] Error 1 > > make[2]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' > > make[1]: *** [all-gdb] Error 2 > > make[1]: Leaving directory > > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' > > make: *** [all] Error 2 > > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake > > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo > > > > --procedure-- -line- -file--- > > exec -- > > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile > > 4 > > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > Any hints? Wrong yacc? > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 4 19:02:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 4 Jul 2009 13:02:37 -0400 Subject: [M3devel] multiarch In-Reply-To: References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> Message-ID: <20090704170237.GB26647@topoi.pooq.com> On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote: > > The Python thing as I understand it, is that sometimes package foo > depends on package bar, and they must be of the same architecture, and > sometimes not. Specifically inproc "plugins" require matching > architecture, but if I just run an executable, architecture doesn't > usually have to match. An executable has to be one of the architectures the processor will handle. And if it uses shared libraries, they have to have matching architecture. The whole worry about multiarch on Linux AMD-64 is to have a consistent way of identifying the compatible one of a set of same-names libraries, and doing this in such a way that it generalises to more architectures (because they *will* eventually show up) and won't confuse the package manager. I think the real point with python is that python code is architecture-independent, because it's handled by an architecture-dependent interpreter. Which makes it, in effect, an extra architecture that's available everywhere, whether you have an AMD-64 or other multiarch CPU or not. > OpenBSD sets an interesting counterexample -- no biarch/multiarch, > just one architecture, "same as it ever was", "no additional > complexity", everything is built from source anyway". And they probably do not in any way support 32-bit proprietary binary-only device drivers or Flash interpreters or anything like that on AMD-64. Building from source is the traditional Modula-3 way of handling packages. To do this with the Debian package-manager, we'd have to include an install-dependency on cm3-min and let the post-install script use the compiler to compile the package and ship it to the proper place. How to do this multiarch is not clear -- We might end up with a number of different architecture versions of the packages, which have identical contents (they're source code). Being labelled with different architectures might (here's hoping the multiarch project thinks of this) end up invoking the appropriate cm3-min binary ... I suspect having real binary packages for different architectures is the Debian way, however. Using source packages is the norm on gentoo. And cm3-min would have to be binary in any case, otherwise there would be no way to compile it. But the multiarch stuff might indicate where we want to ship our libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 or whatever the multiarch people choose. We're already using similar conventions in the choince of LINUXLIBC6 and such names. -- hendrik From mika at async.caltech.edu Sat Jul 4 19:21:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 04 Jul 2009 10:21:11 -0700 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: Your message of "Sat, 04 Jul 2009 15:33:48 -0000." Message-ID: <200907041721.n64HLCr7015429@taps.cs.caltech.edu> I guarantee that this "yacc" is not a faithful yacc. "k" is the first initial of Karl Papadantonakis, the caltech-parser package's author. Mika Jay writes: >--_682f6248-704f-461d-9237-1a192e95b6fb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >It built ok for me a second time. > >The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-= >cvs-uped m3-sys/m3gdb. > >=20 > >yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src. > >=20 > >As long as nothing depend on running it by that name=2C and assuming it isn= >'t a faithful replacement for other Yacc's=2C probably should rename it m3y= >acc=2C or kyacc=2C whatever that means. > >=20 > >You might just try rm -rf m3gdb and cvs -z3 upd -dAP. > >Maybe there is/was a timestamp problem. > >As Rodney said=2C it shouldn't need to run yacc=2C even if your yacc is mes= >sed up. > >=20 > > - Jay > >=20 > > >From: jay.krell at cornell.edu >To: rodney.m.bates at cox.net=3B m3devel at elegosoft.com >Date: Sat=2C 4 Jul 2009 15:28:24 +0000 >Subject: Re: [M3devel] building m3gdb on AMD64_LINUX > > > >It built ok for me=2C but there is a suspicous /usr/local/cm3/bin/yacc. >I'm investigating more=2C but maybe not right now. >=20 > - Jay > >=20 >> Date: Fri=2C 3 Jul 2009 16:53:31 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] building m3gdb on AMD64_LINUX >>=20 >> On my AMD64_LINUX machine (Ubuntu 8.04.2)=2C on which m3gdb builds=2C yac= >c >> is circuitously symlinked to a script that executes /usr/bin/bison -y. >>=20 >> In any case=2C usually=2C there is no need to execute yacc when building= >=20 >> (m3)gdb=2C >> because its output is already present and newer than yacc's input=2C in=20 >> this case=2C >> c-exp.y. I think this is the way it is in the CVS repository. Did some=20 >> dates >> in your source copy get touched? >>=20 >> I have no idea where the c-exp.t file it wants is supposed to come from. >> In a brief look=2C I didn't find any reference to a *.t file at all=2C=20 >> either in the script >> m3gdb/gdb/ylwrap=2C nor in the yacc man page (which actually leads to the >> bison man page on my machine). Maybe original yacc does something=20 >> with it.=20 >> I would have thought ylwrap would have been written to work with a number >> of varieties of yacc and equivalents.=20 >>=20 >> Do you have a copy of c-exp.y? >>=20 >> I suspect having a newer c-exp.c than c-exp.y will circumvent this=20 >> problem=2C but >> of course we probably want it set up to work when c-exp.c needs to be=20 >> rebuilt. >>=20 >> Olaf Wagner wrote: >> > building m3gdb on birch ends with >> > >> > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config=20 >> > -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -DHAVE_CONFIG_H=20 >> > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/..=20 >> > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl=20 >> > -I../../gdb/gdb/../intl -DMI_OUT=3D1 -DTUI=3D1 -Wimplicit -Wreturn-type= >=20 >> > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith=20 >> > -Wformat-nonliteral -Wunused-label -Wunused-function=20 >> > ../../gdb/gdb/tui/tui-winsource.c >> > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c=20 >> > c-exp.c.tmp -- yacc >> > Cannot open=20 >> > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp= >.t"=20 >> > >> > make[2]: *** [c-exp.c] Error 1 >> > make[2]: Leaving directory=20 >> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' >> > make[1]: *** [all-gdb] Error 2 >> > make[1]: Leaving directory=20 >> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' >> > make: *** [all] Error 2 >> > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile"=2C line 121: quake= >=20 >> > runtime error: exit 2: make CC=3D"gcc" CFLAGS=3D"-g" MAKEINFO=3Decho >> > >> > --procedure-- -line- -file--- >> > exec -- >> > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> > 4=20 >> > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args >> > >> > Fatal Error: package build failed >> > >> > Any hints? Wrong yacc? >> > >> > Olaf >>=20 > >--_682f6248-704f-461d-9237-1a192e95b6fb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >It built ok for me a second time.
    >The =3Bsecond time I removed /usr/local/cm3/bin from =3B$PATH and d= >eleted and re-cvs-uped m3-sys/m3gdb.
    > =3B
    >yacc =3Bcomes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src.> > =3B
    >As long as nothing depend on running it by that name=2C and assuming it isn= >'t a faithful =3Breplacement for other Yacc's=2C probably should rename= > it m3yacc=2C or kyacc=2C whatever that means.
    > =3B
    >You might just try rm -rf m3gdb and cvs -z3 upd -dAP.
    >Maybe there is/was a timestamp problem.
    >As Rodney said=2C it shouldn't need to run yacc=2C even if your yacc is mes= >sed up.
    > =3B
    > =3B - Jay

     =3B
    >
    >From: jay.krell at cornell.edu
    To: rodney.m.bates at cox.net=3B m3devel at elegos= >oft.com
    Date: Sat=2C 4 Jul 2009 15:28:24 +0000
    Subject: Re: [M3devel]= > building m3gdb on AMD64_LINUX

    > >It built ok for me=2C but there is a =3Bsuspicous /usr/local/cm3/bin/ya= >cc.
    I'm =3Binvestigating more=2C but =3Bmaybe not right now.
    = > =3B
     =3B- Jay

     =3B
    >=3B Date: Fri=2C 3 Jul 2009= > 16:53:31 -0500
    >=3B From: rodney.m.bates at cox.net
    >=3B To: m3deve= >l at elegosoft.com
    >=3B Subject: Re: [M3devel] building m3gdb on AMD64_LI= >NUX
    >=3B
    >=3B On my AMD64_LINUX machine (Ubuntu 8.04.2)=2C on wh= >ich m3gdb builds=2C yacc
    >=3B is circuitously symlinked to a script th= >at executes /usr/bin/bison -y.
    >=3B
    >=3B In any case=2C usually= >=2C there is no need to execute yacc when building
    >=3B (m3)gdb=2C>>=3B because its output is already present and newer than yacc's input= >=2C in
    >=3B this case=2C
    >=3B c-exp.y. I think this is the way i= >t is in the CVS repository. Did some
    >=3B dates
    >=3B in your sou= >rce copy get touched?
    >=3B
    >=3B I have no idea where the c-exp.t= > file it wants is supposed to come from.
    >=3B In a brief look=2C I did= >n't find any reference to a *.t file at all=2C
    >=3B either in the scr= >ipt
    >=3B m3gdb/gdb/ylwrap=2C nor in the yacc man page (which actually = >leads to the
    >=3B bison man page on my machine). Maybe original yacc d= >oes something
    >=3B with it.
    >=3B I would have thought ylwrap wo= >uld have been written to work with a number
    >=3B of varieties of yacc = >and equivalents.
    >=3B
    >=3B Do you have a copy of c-exp.y?
    &g= >t=3B
    >=3B I suspect having a newer c-exp.c than c-exp.y will circumve= >nt this
    >=3B problem=2C but
    >=3B of course we probably want it s= >et up to work when c-exp.c needs to be
    >=3B rebuilt.
    >=3B
    &g= >t=3B Olaf Wagner wrote:
    >=3B >=3B building m3gdb on birch ends with<= >BR>>=3B >=3B
    >=3B >=3B gcc -c -g -I. -I../../gdb/gdb -I../../gdb= >/gdb/config
    >=3B >=3B -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -= >DHAVE_CONFIG_H
    >=3B >=3B -I../../gdb/gdb/../include/opcode -I../../= >gdb/gdb/../readline/..
    >=3B >=3B -I../bfd -I../../gdb/gdb/../bfd -I= >../../gdb/gdb/../include -I../intl
    >=3B >=3B -I../../gdb/gdb/../int= >l -DMI_OUT=3D1 -DTUI=3D1 -Wimplicit -Wreturn-type
    >=3B >=3B -Wcomme= >nt -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith
    >=3B >=3B -Wf= >ormat-nonliteral -Wunused-label -Wunused-function
    >=3B >=3B ../../g= >db/gdb/tui/tui-winsource.c
    >=3B >=3B /bin/sh ../../gdb/gdb/../ylwrap= > ../../gdb/gdb/c-exp.y y.tab.c
    >=3B >=3B c-exp.c.tmp -- yacc
    >= >=3B >=3B Cannot open
    >=3B >=3B "/home/wagner/work/cm3/m3-sys/m3gd= >b/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t"
    >=3B >=3B
    >=3B >=3B= > make[2]: *** [c-exp.c] Error 1
    >=3B >=3B make[2]: Leaving directory= >
    >=3B >=3B `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb'
    = >>=3B >=3B make[1]: *** [all-gdb] Error 2
    >=3B >=3B make[1]: Leav= >ing directory
    >=3B >=3B `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_L= >INUX'
    >=3B >=3B make: *** [all] Error 2
    >=3B >=3B "/home/wagn= >er/work/cm3/m3-sys/m3gdb/src/m3makefile"=2C line 121: quake
    >=3B >= >=3B runtime error: exit 2: make CC=3D"gcc" CFLAGS=3D"-g" MAKEINFO=3Decho>>=3B >=3B
    >=3B >=3B --procedure-- -line- -file---
    >=3B >= >=3B exec -- <=3Bbuiltin>=3B
    >=3B >=3B m3gdb_Run 121 /home/wagner= >/work/cm3/m3-sys/m3gdb/src/m3makefile
    >=3B >=3B include_dir 160 /hom= >e/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile
    >=3B >=3B 4
    >=3B= > >=3B /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args
    >= >=3B >=3B
    >=3B >=3B Fatal Error: package build failed
    >=3B >= >=3B
    >=3B >=3B Any hints? Wrong yacc?
    >=3B >=3B
    >=3B >= >=3B Olaf
    >=3B
    >= > >--_682f6248-704f-461d-9237-1a192e95b6fb_-- From jay.krell at cornell.edu Sat Jul 4 19:24:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 4 Jul 2009 17:24:24 +0000 Subject: [M3devel] multiarch In-Reply-To: <20090704170237.GB26647@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> <20090704170237.GB26647@topoi.pooq.com> Message-ID: I think Python code simply depends on the Python interpreter. I skimmed through the document. The point I gleaned about interpreters is that sometimes a dependency is on an interpreter because the package is a "plugin" or "extension" written in C or such, and sometimes the dependency is because a program is written in "pure" Python (Tcl, Perl, etc.) and just needs "any" interpreter that will run. That is, if I have: hello.py: print("hello") I am dependent on Python, but on an AMD64 system, it can be the x86 Python or AMD64 Python (or heck, Jython or IronPython, implementations in Java and for .NET/Mono). I see your point that Python could be considered an "architecture" and the Python interpreter could be seen as installing the processor. I didn't get that from the spec but should read it more closely. There were some references here to qemu that I didn'd understand but might make sense in that light. That is, maybe, maybe I could have "all architectures" in one file system and maybe some virtualization products use the host file system as a file system and not just store some virtual disk in it. I agree OpenBSD is a bit spartan/draconion/etc. My point about source builds was more to reflect the seeming "OpenBSD way" (Gentoo, SourceMage, etc.), not necessarily what is or should be the Modula-3 way. There's a real dilemna between the two options of binary packages and source builds. They each have advantages/disadvantages. - Jay > Date: Sat, 4 Jul 2009 13:02:37 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiarch > > On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote: > > > > The Python thing as I understand it, is that sometimes package foo > > depends on package bar, and they must be of the same architecture, and > > sometimes not. Specifically inproc "plugins" require matching > > architecture, but if I just run an executable, architecture doesn't > > usually have to match. > > An executable has to be one of the architectures the processor will > handle. And if it uses shared libraries, they have to have matching > architecture. The whole worry about multiarch on Linux AMD-64 is to > have a consistent way of identifying the compatible one of a set > of same-names libraries, and doing this in such a way that it > generalises to more architectures (because they *will* eventually show > up) and won't confuse the package manager. > > I think the real point with python is that python code is > architecture-independent, because it's handled by an > architecture-dependent interpreter. Which makes it, in effect, an > extra architecture that's available everywhere, whether you have an > AMD-64 or other multiarch CPU or not. > > > OpenBSD sets an interesting counterexample -- no biarch/multiarch, > > just one architecture, "same as it ever was", "no additional > > complexity", everything is built from source anyway". > > And they probably do not in any way support 32-bit proprietary > binary-only device drivers or Flash interpreters or anything like that > on AMD-64. > > Building from source is the traditional Modula-3 way of handling > packages. To do this with the Debian package-manager, we'd have to > include an install-dependency on cm3-min and let the post-install > script use the compiler to compile the package and ship it to the > proper place. > > How to do this multiarch is not clear -- We might end up with a number > of different architecture versions of the packages, which have identical > contents (they're source code). Being labelled with different > architectures might (here's hoping the multiarch project thinks of this) > end up invoking the appropriate cm3-min binary ... > > I suspect having real binary packages for different architectures is the > Debian way, however. Using source packages is the norm on gentoo. > And cm3-min would have to be binary in any case, otherwise there would > be no way to compile it. > > But the multiarch stuff might indicate where we want to ship our > libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 > or whatever the multiarch people choose. We're already using similar > conventions in the choince of LINUXLIBC6 and such names. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 4 19:55:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 04 Jul 2009 19:55:21 +0200 Subject: [M3devel] building m3gdb on AMD64_LINUX In-Reply-To: <4A4E7DDB.2090107@cox.net> References: <20090703213642.fz30ggj0r6ss0ogk@mail.elegosoft.com> <4A4E7DDB.2090107@cox.net> Message-ID: <20090704195521.1g2ictqykgocc0sg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc > is circuitously symlinked to a script that executes /usr/bin/bison -y. > > In any case, usually, there is no need to execute yacc when building (m3)gdb, > because its output is already present and newer than yacc's input, in > this case, > c-exp.y. I think this is the way it is in the CVS repository. Did > some dates > in your source copy get touched? > > I have no idea where the c-exp.t file it wants is supposed to come from. > In a brief look, I didn't find any reference to a *.t file at all, > either in the script > m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the > bison man page on my machine). Maybe original yacc does something > with it. I would have thought ylwrap would have been written to work > with a number > of varieties of yacc and equivalents. Do you have a copy of c-exp.y? > > I suspect having a newer c-exp.c than c-exp.y will circumvent this > problem, but > of course we probably want it set up to work when c-exp.c needs to > be rebuilt. I now removed everything, including the source, and checked out the package anew. Then the build completed without problems. Thanks for the help, Olaf > Olaf Wagner wrote: >> building m3gdb on birch ends with >> >> gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config >> -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H >> -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. >> -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include >> -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit >> -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses >> -Wpointer-arith -Wformat-nonliteral -Wunused-label >> -Wunused-function ../../gdb/gdb/tui/tui-winsource.c >> /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c >> c-exp.c.tmp -- yacc >> Cannot open >> "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" >> make[2]: *** [c-exp.c] Error 1 >> make[2]: Leaving directory >> `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb' >> make[1]: *** [all-gdb] Error 2 >> make[1]: Leaving directory `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX' >> make: *** [all] Error 2 >> "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: >> quake runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo >> >> --procedure-- -line- -file--- >> exec -- >> m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile >> 4 >> /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args >> >> Fatal Error: package build failed >> >> Any hints? Wrong yacc? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sun Jul 5 21:36:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 5 Jul 2009 15:36:06 -0400 Subject: [M3devel] multiarch In-Reply-To: References: <20090703231254.GA25415@topoi.pooq.com> <20090703231509.GB25415@topoi.pooq.com> <20090704170237.GB26647@topoi.pooq.com> Message-ID: <20090705193606.GA31710@topoi.pooq.com> On Sat, Jul 04, 2009 at 05:24:24PM +0000, Jay wrote: > > My point about source builds was more to reflect the seeming "OpenBSD > way" (Gentoo, SourceMage, etc.), not necessarily what is or should be > the Modula-3 way. There's a real dilemna between the two options of > binary packages and source builds. They each have > advantages/disadvantages. One of the differences is that with a binary package, if we fix a big in the compiler package that might affect object code, it is necessary to produce new versions of all the packages that were compiled with it. If we have source packages, the package manager will have to discover that recompilation is necessary. And if we send source packages masquerading as binary packages (via post-install scripts or some such) we have to rerelease identical packages with a new version number, just to ensure recompilation. It seems that the thing to do is build packages that match the target system's predilections. If there are too many target systems, we'll have to do is our way and ignore the target system's conventions. Or maybe provide special packagings for a few important platforms. I gather that Windows is such a system. And I'm hoping Debian is. In any case, the compiler itself will have to be a binary package, because of bootstrapping. I think this discussion is starting to belabor the obvious. Is it useful to go on? I started this thread merely to report that others are starting to deal with multiarchitecture issues, and we might as well be aware of what they're doing. -- hendrik From eiserlohpp at yahoo.com Mon Jul 6 19:00:19 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 6 Jul 2009 10:00:19 -0700 (PDT) Subject: [M3devel] WDROOT private repository not working? Message-ID: <67172.22662.qm@web56806.mail.re3.yahoo.com> Hi Guys, Seeing all the attention placed on creating relative linking, and so forth, I decided to examine the behavior of CM3, when building for a private root. So, I set WDROOT to ${HOME}/m3work in my m3makefile. ---- BEGIN m3makefile ---- %# Time-Space-Position Information (TSPI) library HOME = "/home/peter" WDROOT = HOME & "/m3work" include_dir("xform") % include_dir("smoothing") % include_dir("editing") % include_dir("geoid") % include_dir("testing") ---- EMD m3makefile ---- Then I, attempted to build and ship from there. It said, there was an error ---- BEGIN ERROR MSG ---- peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship --- shipping from ../AMD64_LINUX --- "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/usr/lib/cm3/pkg/tspi": errno=13 --procedure-- -line- -file--- make_dir -- 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP ---- END ERROR MSG ---- Was support for WDROOT removed? Can CM3 support the ability to have a private repository, while also having the public repo? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Mon Jul 6 20:49:21 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 6 Jul 2009 11:49:21 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 33, Issue 25 Message-ID: <208085.23533.qm@web56807.mail.re3.yahoo.com> Hi Olaf, > Date: Fri, 03 Jul 2009 11:22:05 +0200 > From: Olaf Wagner > Subject: [M3devel] Some comments about package structure > and package > pools, was: > Re: ROOT > To: m3devel at elegosoft.com > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com> > Content-Type: text/plain; charset=ISO-8859-15; >The CM3 builder needs to be extended to search a set of pools >instead of just one (INSTALL_ROOT). This could be expressed by >a CM3_POOL_PATH, similar to the Java class path: > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 Yes, I like it. I could then ship my data reduction libraries to an appropriate "pool", and then all the different programs that make use of those libraries, can access them. This would not require "root" privileges. If this were a work group pool, then it would only need "group" ones. If a private pool such as ${HOME}/m3work (the old WDROOT), I wouldn't need any special privileges. How would we specify the pool to which we desire to ship? Command line argument? --pool-install-path=${MYPROJECT}/m3pool -p ${MYPROJECT}/m3pool Environment Variable? M3_INSTALL_POOL=${MYPROJECT}/m3pool > >To satisfy package imports, the builder would start searching in the >first pool and continue until it has found an appropriate package. >This way local or project changes could easily be tested and integrated >before being `promoted' to a higher level. > >For backward compatibility reasons, there should be a default pool >(/usr/local/cm3) which is used when nothing else is defined. We could also make use of the paths built into M3Config, as part of the default search pool path. That is the reason that M3Config exists, so M3 programs can find at run-time the main installation pool, and its components (bin, lib, pkg, ..., etc). +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Mon Jul 6 22:17:03 2009 From: jay.krell at cornell.edu (Jay lastname) Date: Mon, 6 Jul 2009 20:17:03 +0000 Subject: [M3devel] WDROOT private repository not working? In-Reply-To: <67172.22662.qm@web56806.mail.re3.yahoo.com> References: <67172.22662.qm@web56806.mail.re3.yahoo.com> Message-ID: I think WDROOT was only ever a synonym for ROOT -- the root of the source tree, available for overrides to get "builtlocal" unshipped stuff. This does somewhat resemble what Olaf was talking about, but it is referencing, essentially, the source tree, in a different layout than the shipped tree. Instead Olaf and I advocate multiple (I think two is maybe enough) roots with the same layout as the shipped/installed system, instead of one shipped and one unshipped. All outputs that would be shipped should just go to this place, rather than first to build_dir and then later copied into the right layout. They might still be copied, but it would not be a layout changing copy. (And yes, this mechanism does work.) Searching for 'wdroot'... C:\dev2\cm3.2\m3-db\stable\example\src\m3makefile(7):override ("stable", WDROOT) % try to pick up the local copy C:\dev2\cm3.2\m3-libs\arithmetic\test\src\m3overrides(1):%override("arithmetic",WDROOT) C:\dev2\cm3.2\m3-libs\lapack\test\src\m3overrides(1):%override("lapack",WDROOT) C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(350):.BR WDROOT , C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(516):.B WDROOT C:\dev2\cm3.2\m3-sys\cm3\src\m3makefile.7(554):.B WDROOT C:\dev2\cm3.2\m3-sys\m3loader\src\m3makefile(10): override ("winlib", WDROOT) C:\dev2\cm3.2\m3-tools\m3tk\src\files\m3overrides.not(1):override(m3tk-misc.3.1, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(9):% override ("vbtkit", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(10):% override ("formsvbt", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(11):%override ("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\m3overrides(12):%override ("juno-compiler", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\src\m3overrides(10):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\compiler\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\compiler\src\m3overrides(10):%override("juno-compiler", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\lexer\src\m3overrides(9):override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\lexer\src\m3overrides(10):override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\parser\src\m3overrides(9):%override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\parser\src\m3overrides(10):%override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\scope\src\m3overrides(9):%override(juno-machine, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-compiler\tests\scope\src\m3overrides(10):%override(juno-compiler, WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\linear\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\nonlinear\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\runtime\src\m3overrides(9):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-ui\juno-2\juno-machine\solve\src\m3overrides(3):%override("juno-machine", WDROOT) C:\dev2\cm3.2\m3-www\http\src\m3makefile(7):%write("WDROOT = ", WDROOT, CR) 26 occurrence(s) have been found. - Jay > Date: Mon, 6 Jul 2009 10:00:19 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] WDROOT private repository not working? > > > Hi Guys, > > Seeing all the attention placed on creating relative > linking, and so forth, I decided to examine the behavior > of CM3, when building for a private root. > > So, I set WDROOT to ${HOME}/m3work in my m3makefile. > > ---- BEGIN m3makefile ---- > %# Time-Space-Position Information (TSPI) library > > HOME = "/home/peter" > WDROOT = HOME & "/m3work" > > include_dir("xform") > % include_dir("smoothing") > % include_dir("editing") > % include_dir("geoid") > % include_dir("testing") > ---- EMD m3makefile ---- > > > Then I, attempted to build and ship from there. > > It said, there was an error > > ---- BEGIN ERROR MSG ---- > peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship > --- shipping from ../AMD64_LINUX --- > > "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/usr/lib/cm3/pkg/tspi": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP > > ---- END ERROR MSG ---- > > > > Was support for WDROOT removed? Can CM3 support the ability to > have a private repository, while also having the public repo? > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 6 22:31:02 2009 From: jay.krell at cornell.edu (Jay lastname) Date: Mon, 6 Jul 2009 20:31:02 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <208085.23533.qm@web56807.mail.re3.yahoo.com> References: <208085.23533.qm@web56807.mail.re3.yahoo.com> Message-ID: Just fyi..I see this all maybe slightly differently. I'm not sure it works well beyond two pools. I'm not sure it works well with sparse pools -- particularly if $ORIGIN is used. Roughly I see it that there are two pools, ROOT/pkg and CM3_INSTALL/pkg. You build into ROOT/pkg and ship from ROOT/pkg to CM3_INSTALL/pkg. Ship, or promote, is possibly an entire pkg store to pkg store operation, not individual packages. If you remove the use of origin, then it might become easier to use multiple pools and sparse pool, however, imagine you build and ship a private m3core.so. Which programs and .so files are supposed to use that? If that is only the thing you build/ship, nothing will use it. Arguably that is correct, since nothing has been built against its possibly changed interfaces. Arguably all pools must be built up from the bottom of the dependency tree and on up. And the only allowed "sparseness" is that you don't "finish". This strikes at why you can't ship after buildlocal. That isn't the right restriction -- if you buildlocal "everything", then you have coherence and should be able to ship everything (but not selectively). However, now I painted ourselves into a perhaps less interesting corner and in fact the same place we already are -- you can always build up a new package store from scratch from the bottom of the dependency tree and on up. You can always put together a system as non-root. Now, let's consider if $ORIGIN is removed. In fact, by default we use $ORIGIN and full paths. Now you can have sparse or incomplete package stores but you have to be careful. I'm not sure how to formulate what the restrictions are, but for example, if you were to build and ship out of dependency order, you could end up with a system where multiple versions of the "same" .so files are in use, and it might or might not matter. You could have pkg1/m3core.so pkg1/libm3.so pkg2/m3core.so pkg2/libm3.so pkg2/libfoo.so pkg2/libbar.so libbar.so might depend on pkg1/libm3.so and pkg1/m3core.so and libfoo.so might depend on pkg2/libm3.so, pkg2/m3core.so. Depending on the order you built/shipped in. If libbar.so and libfoo.so never pass types to each other defined in m3core, then this is probably ok. However you might end up with multiple garbage collectors trying to free the same storage. I suggested that each package store be created by cloning the next one in the list. That helps address these situations. But "clone" vs. build from scratch from the bottom of the dependency tree and on up are, are similar. - Jay > Date: Mon, 6 Jul 2009 11:49:21 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 25 > > > Hi Olaf, > > > > Date: Fri, 03 Jul 2009 11:22:05 +0200 > > From: Olaf Wagner > > Subject: [M3devel] Some comments about package structure > > and package > > pools, was: > > Re: ROOT > > To: m3devel at elegosoft.com > > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com> > > Content-Type: text/plain; charset=ISO-8859-15; > > > >The CM3 builder needs to be extended to search a set of pools > >instead of just one (INSTALL_ROOT). This could be expressed by > >a CM3_POOL_PATH, similar to the Java class path: > > > > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3 > > Yes, I like it. I could then ship my data reduction > libraries to an appropriate "pool", and then all the > different programs that make use of those libraries, > can access them. This would not require "root" privileges. > If this were a work group pool, then it would only need > "group" ones. If a private pool such as ${HOME}/m3work > (the old WDROOT), I wouldn't need any special privileges. > > How would we specify the pool to which we desire to ship? > Command line argument? > > --pool-install-path=${MYPROJECT}/m3pool > -p ${MYPROJECT}/m3pool > > Environment Variable? > M3_INSTALL_POOL=${MYPROJECT}/m3pool > > > > > >To satisfy package imports, the builder would start searching in the > >first pool and continue until it has found an appropriate package. > >This way local or project changes could easily be tested and integrated > >before being `promoted' to a higher level. > > > >For backward compatibility reasons, there should be a default pool > >(/usr/local/cm3) which is used when nothing else is defined. > > We could also make use of the paths built into M3Config, > as part of the default search pool path. That is the > reason that M3Config exists, so M3 programs can find at > run-time the main installation pool, and its components > (bin, lib, pkg, ..., etc). > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Tue Jul 7 02:49:36 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Mon, 6 Jul 2009 20:49:36 -0400 Subject: [M3devel] multiple pkg roots In-Reply-To: References: <208085.23533.qm@web56807.mail.re3.yahoo.com> Message-ID: <4A526360.1E75.00D7.1@scires.com> >From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose. The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--ie. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight. Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose. Perhaps my understanding of what is meant by "pool" needs clarification? Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Tue Jul 7 06:49:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 04:49:19 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <4A526360.1E75.00D7.1@scires.com> References: <208085.23533.qm@web56807.mail.re3.yahoo.com> <4A526360.1E75.00D7.1@scires.com> Message-ID: I believe these two things are highly related. When you have a multiple pool environment, you must be careful what you replace and in what order. Otherwise you end up with inconsistencies. As well, you possibly need a "runpath" that includes every pool -- i.e. you can't use $ORIGIN, you maybe can, maybe should not use full paths in runpath, probably using an LD_LIBRARY_PATH that shadows the pool list is what people expect. OR, what I described: you don't have any incomplete pools. Every "earlier" pool is initially a copy of any later pool. But then, you don't need any "list" of pools, you just need to create new pools, such as by copying or linking with copy-on-write from an existing pool. I still think there is something to be done here however. I think the initial unshipped output should be in the same or more similar directory structure as a shipped pool/package store/repository. For the outputs -- the .so, .m3x, .m3web, .m3exports files, this seems simple and good. The fact that shipping also copies all the source files however, is a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" placed upon output, then ship would just be a recursive copy, or move, or change the root. However "ship" remains "complicated" due to the "need" to ship the sources -- or, do sources not really need to be shipped? One thing I wonder, haven't tracked down, is if sources are shipped because the compiler, i.e. import, needs them, or "only" for debugging? Maybe the .m3x files handle all the import needs, and the .i3 files are never reparsed? Still, surely the source .ig files are shipped because they might be needed. And "only" for debugging is still important. Perhaps perhaps the source should be "shipped" as part of building? You know, they have to be read anyway, so it is not a super wasteful expense. You know, imagine I am in a long edit/compile/test loop, and won't really "ship" till much later -- is it a big waste for "compile" to also copy any changed files to the output directory, even though ultimately they are all dead except for the last version? I use Reactor briefly years ago, the commercial version. I was not impressed. As I recall it claims to be an "IDE", but lacks an editor and debugger, and maybe more. As I recall it is a custom web server, that you use with any browser, and provides not much more than browsing hyperlinked source code. I will try it again soon. Not providing an editor, in retrospect, is probably smart. I was young then and would have tried whatever ideal language oriented editor it came with. Since then I have used the same editor for over 10 years and reasons to change must be /extremely/ strong. Not providing a debugger was also probably not a bad decision, given the effort and system-specific work involved, though maybe a gui wrapper over gdb would be good (e.g. Xcode). - Jay ________________________________ > Date: Mon, 6 Jul 2009 20:49:36 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] multiple pkg roots > > > > > > > > From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose. > > > > The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--i.e. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers. > > > > Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight. > > > > Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose. > > > > Perhaps my understanding of what is meant by "pool" needs clarification? > > > > Regards, > > Randy Coleburn From wagner at elegosoft.com Tue Jul 7 08:26:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 08:26:23 +0200 Subject: [M3devel] WDROOT private repository not working? In-Reply-To: <67172.22662.qm@web56806.mail.re3.yahoo.com> References: <67172.22662.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090707082623.ihmzdg2lw8o8kook@mail.elegosoft.com> WDROOT has no special meaning in CM3, it was just a convention used in _some_ override files. More used just ROOT, so we left it that way years ago. The m3overrides mechanism does work as expected in CM3. If you speficy the -overrides option to the compiler, it additionally reads all m3override files. In almost all overrides shipped with CM3 ROOT is used. Hope this helps, Olaf Quoting Peter Eiserloh : > > Hi Guys, > > Seeing all the attention placed on creating relative > linking, and so forth, I decided to examine the behavior > of CM3, when building for a private root. > > So, I set WDROOT to ${HOME}/m3work in my m3makefile. > > ---- BEGIN m3makefile ---- > %# Time-Space-Position Information (TSPI) library > > HOME = "/home/peter" > WDROOT = HOME & "/m3work" > > include_dir("xform") > % include_dir("smoothing") > % include_dir("editing") > % include_dir("geoid") > % include_dir("testing") > ---- EMD m3makefile ---- > > > Then I, attempted to build and ship from there. > > It said, there was an error > > ---- BEGIN ERROR MSG ---- > peter at black:/data/modula-3/peters-stuff/tspi/src $ cm3 -ship > --- shipping from ../AMD64_LINUX --- > > "/data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP", line 1: > quake runtime error: unable to create directory > "/usr/lib/cm3/pkg/tspi": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 1 /data/modula-3/peters-stuff/tspi/AMD64_LINUX/.M3SHIP > > ---- END ERROR MSG ---- > > > > Was support for WDROOT removed? Can CM3 support the ability to > have a private repository, while also having the public repo? > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Tue Jul 7 08:54:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Jul 2009 23:54:58 -0700 Subject: [M3devel] multiple pkg roots In-Reply-To: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." Message-ID: <200907070654.n676swq8048959@taps.cs.caltech.edu> Jay K writes: > >a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla >ced upon output, then ship would just be a recursive copy, or move, or change >the root. However "ship" remains "complicated" due to the "need" to ship the s >ources -- or, do sources not really need to be shipped? One thing I wonder, ha >ven't tracked down, is if sources are shipped because the compiler, i.e. impor >t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im >port needs, and the .i3 files are never reparsed? Still, surely the source .ig > files are shipped because they might be needed. And "only" for debugging is s >till important. Perhaps perhaps the source should be "shipped" as part of buil >ding? You know, they have to be read anyway, so it is not a super wasteful exp >ense. You know, imagine I am in a long edit/compile/test loop, and won't reall >y "ship" till much later -- is it a big waste for "compile" to also copy any c >hanged files to the output directory, even though ultimately they are all dead > except for the last version? Isn't the main purpose of any programming language that it is used for human-to-human communication? The .i3s need to be shipped so that programmers can see the interface of the libraries they are using, whether it be for debugging or initial development. That also means they should be shipped precisely when the binaries are shipped (they have to remain synchronized). Things would get extremely confusing if sources (I'd prefer to call them "interfaces"---you don't have to ship the "implementation modules") and binaries are shipped at different times. Mika From jay.krell at cornell.edu Tue Jul 7 09:05:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 07:05:54 +0000 Subject: [M3devel] multiple pkg roots In-Reply-To: <200907070654.n676swq8048959@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." <200907070654.n676swq8048959@taps.cs.caltech.edu> Message-ID: Mostly agreed. It's just, you know, there is a contradiction between "making ship just a recursive copy or link" and "not wastefully copying files" Given that files would only be copied when they change, and when they change they have to read anyway, maybe it's not so bad. The dilemna is whether or not "build" copies the sources, so that ship is just recursive copy/link, or if build shouldn't waste time doing so and ship would continue to do all/some directory layout changes. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 6 Jul 2009 23:54:58 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] multiple pkg roots > > Jay K writes: >> >>a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla >>ced upon output, then ship would just be a recursive copy, or move, or change >>the root. However "ship" remains "complicated" due to the "need" to ship the s >>ources -- or, do sources not really need to be shipped? One thing I wonder, ha >>ven't tracked down, is if sources are shipped because the compiler, i.e. impor >>t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im >>port needs, and the .i3 files are never reparsed? Still, surely the source .ig >> files are shipped because they might be needed. And "only" for debugging is s >>till important. Perhaps perhaps the source should be "shipped" as part of buil >>ding? You know, they have to be read anyway, so it is not a super wasteful exp >>ense. You know, imagine I am in a long edit/compile/test loop, and won't reall >>y "ship" till much later -- is it a big waste for "compile" to also copy any c >>hanged files to the output directory, even though ultimately they are all dead >> except for the last version? > > Isn't the main purpose of any programming language that it is used > for human-to-human communication? > > The .i3s need to be shipped so that programmers can see the interface > of the libraries they are using, whether it be for debugging or > initial development. That also means they should be shipped precisely > when the binaries are shipped (they have to remain synchronized). > Things would get extremely confusing if sources (I'd prefer to call > them "interfaces"---you don't have to ship the "implementation > modules") and binaries are shipped at different times. > > Mika From wagner at elegosoft.com Tue Jul 7 11:28:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 11:28:15 +0200 Subject: [M3devel] multiple pkg roots In-Reply-To: References: Your message of "Tue, 07 Jul 2009 04:49:19 -0000." <200907070654.n676swq8048959@taps.cs.caltech.edu> Message-ID: <20090707112815.hn3o411jc4kc8ow4@mail.elegosoft.com> Just some short comments from me before I leave you again for a while: o My suggestion of using multiple pools is just a generalization of the existing PKGROOT concept. It's intended to better support project and team setups in software development. There was no intention to use this to support `CM3 evolution' as Randy calls it (though it could be used for it). o I would not like to restrict the concept to two pools or levels. o For a first step, I'd suggest to keep thing really simple: - make cm3 understand a CM3_POOL_PATH to satisfy imports - only ship to the leftmost pool in the path - mark the hierarchy level in the pools (e.g. 0: system global, 1: project level, 2: individual workspace level) - disallow shipping when packages from lower pools than the one shipped to are referenced This way, there is no explicit promote operation (that can be added later), but we should be able to keep the dependencies correct easily. (I haven't thought this through completely though, so I may be mistaken.) I just realize that this might not be correct though: if a library package is locally modified and tested in a local pool, we'd probably like the other importers in the global pool to use our new dependency, too, or we'd end up with two versions of the same library in our program, which would probably neither work (names clashes) nor be what we intended: so we'd have to teach cm3 to detect those `invalid' importers and forbid us to use them. I.e. modifying a base library would require us to recompile (and probably adapt) all depending packages. It seems that all this needs more and careful consideration... o I also strongly suggest to postpone all this until we've finished the current release. Olaf Quoting Jay K : > > Mostly agreed. > It's just, you know, there is a contradiction between > "making ship just a recursive copy or link" > and > "not wastefully copying files" > > > Given that files would only be copied when they change, and when > they change they have to read anyway, maybe it's not so bad. > > > The dilemna is whether or not "build" copies the sources, so that > ship is just recursive copy/link, or if build shouldn't waste time > doing so and ship would continue to do all/some directory layout > changes. > > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon, 6 Jul 2009 23:54:58 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] multiple pkg roots >> >> Jay K writes: >>> >>> a wrinkle. That is, if it were just the output .so, .m3x etc., >>> "correctly" pla >>> ced upon output, then ship would just be a recursive copy, or >>> move, or change >>> the root. However "ship" remains "complicated" due to the "need" >>> to ship the s >>> ources -- or, do sources not really need to be shipped? One thing >>> I wonder, ha >>> ven't tracked down, is if sources are shipped because the >>> compiler, i.e. impor >>> t, needs them, or "only" for debugging? Maybe the .m3x files >>> handle all the im >>> port needs, and the .i3 files are never reparsed? Still, surely >>> the source .ig >>> files are shipped because they might be needed. And "only" for >>> debugging is s >>> till important. Perhaps perhaps the source should be "shipped" as >>> part of buil >>> ding? You know, they have to be read anyway, so it is not a super >>> wasteful exp >>> ense. You know, imagine I am in a long edit/compile/test loop, and >>> won't reall >>> y "ship" till much later -- is it a big waste for "compile" to >>> also copy any c >>> hanged files to the output directory, even though ultimately they >>> are all dead >>> except for the last version? >> >> Isn't the main purpose of any programming language that it is used >> for human-to-human communication? >> >> The .i3s need to be shipped so that programmers can see the interface >> of the libraries they are using, whether it be for debugging or >> initial development. That also means they should be shipped precisely >> when the binaries are shipped (they have to remain synchronized). >> Things would get extremely confusing if sources (I'd prefer to call >> them "interfaces"---you don't have to ship the "implementation >> modules") and binaries are shipped at different times. >> >> Mika -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 7 14:31:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 12:31:13 +0000 Subject: [M3devel] pkg roots/origin/ld_library_path Message-ID: Really, I understand, but there is a problem nobody seems to see. Let's say there are multiple pkg roots. Remember my question? It is very important. "How are the dependencies of an .so or executable found?" What if I install to /opt/cm3. You install to $HOME/cm3 -- no need for root! We have some root/bin/executable. It uses of course libm3core.so. I want to be able to copy it from machine to machine, probably without relinking it or running some tool over it. People want to install libm3core.so to different places on different machines. Does root/bin/executable refer to /opt/cm3/lib? or $HOME/cm3/lib? or $ORIGIN/../lib? or no directory and user sets LD_LIBRARY_PATH? I'm not even sure you can omit the directory. There is a basic contradiction here. $ORIGIN is good. $ORIGIN is bad. LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. Full paths are good. Full paths are bad. The ability to install to different places is good. The ability to install to different places is bad. You cannot have all of: ability to specify install location AND multiple package roots, where a package root is sparse AND if I install to a custom location, I don't have to set LD_LIBRARY_PATH Now, while I advocate(d) $ORIGIN and custom install locations and no need for LD_LIBRARY_PATH, that approach does devolve to everything being in the same directory, which also seems not great. The difference is often that you don't use $ORIGIN for "well known important stuff". You don't get "libc.so" from $ORIGIN/../lib. You get it from where it always is, like /usr/lib or somesuch. You don't actually ever use a custom install for it. If you want to build your own, you are probably building your own entire system, and might use chroot as part of that. But where is the line between "my stuff" and "well known important stuff"? Where is the line between stuff that can be installed anywhere vs. stuff that must be installed to its "standard" location? - Jay From wagner at elegosoft.com Tue Jul 7 15:05:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Jul 2009 15:05:45 +0200 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: References: Message-ID: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> I understand that the $ORIGIN use in library paths does not work if we want to have hierarchical overrides for an arbitrary set of package pools. We'll either have to use absolute paths or rely on a correct (automatically computed?) LD_LIBRARY_PATH setting. How do $ORIGIN and LD_LIBRARY_PATH work together? Are there consistently defined semantics on different systems? Could we use $ORIGIN just for the one global system installation, and rely on absolute paths for all other pools? Of course we'd loose the ability to just copy from one pool to another this way, but that may not be that important. Anyway, we (at least I) won't work on it right now... Olaf Quoting Jay K : > > Really, I understand, but there is a problem nobody seems to see. > > > Let's say there are multiple pkg roots. > > > Remember my question? It is very important. > "How are the dependencies of an .so or executable found?" > > > What if I install to /opt/cm3. > You install to $HOME/cm3 -- no need for root! > We have some root/bin/executable. > It uses of course libm3core.so. > > > I want to be able to copy it from machine to machine, probably > without relinking it or running some tool over it. > > > People want to install libm3core.so to different places on different > machines. > > > Does root/bin/executable refer > to /opt/cm3/lib? > or $HOME/cm3/lib? > or $ORIGIN/../lib? > or no directory and user sets LD_LIBRARY_PATH? > I'm not even sure you can omit the directory. > > > There is a basic contradiction here. > $ORIGIN is good. $ORIGIN is bad. > LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. > Full paths are good. Full paths are bad. > The ability to install to different places is good. The ability to > install to different places is bad. > > > You cannot have all of: > ability to specify install location > AND multiple package roots, where a package root is sparse > AND if I install to a custom location, I don't have to set LD_LIBRARY_PATH > > > Now, while I advocate(d) $ORIGIN and custom install locations and no > need for LD_LIBRARY_PATH, that approach does devolve to everything > being in the same directory, which also seems not great. > > > The difference is often that you don't use $ORIGIN for "well known > important stuff". > You don't get "libc.so" from $ORIGIN/../lib. You get it from where > it always is, like /usr/lib or somesuch. You don't actually ever use > a custom install for it. If you want to build your own, you are > probably building your own entire system, and might use chroot as > part of that. > > > But where is the line between "my stuff" and "well known important > stuff"? Where is the line between stuff that can be installed > anywhere vs. stuff that must be installed to its "standard" location? > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Tue Jul 7 22:02:53 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Jul 2009 15:02:53 -0500 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <20090703231254.GA25415@topoi.pooq.com> References: <20090703231254.GA25415@topoi.pooq.com> Message-ID: <4A53A9ED.8020908@cox.net> This may only be peripherally related, but since this discussion has come up: I have long wished for a directory, neither src, nor the architecture directory, for files that are mechanically generated but not target dependent. I have an application where there are several machine-generated files containing Modula-3 "source" code. It's "source code", in the sense that it is input to the compiler, but not "source code", in the sense that it is not written by a human using an editor. Some existing quake commands for instantiating generics do similarly. Neither place is entirely appropriate for these files. I have gone through a series of kludgy ways of handling this. Right now, I have them in a directory "derived", beside "src", with lines in m3makefiles that look, e.g., like: 'implementation("../derived/M3InitTokStrings")'. But the instantiating quake functions put generated source code in the arch directory, and sometimes unnecessarily regenerate it. Just something that it would be nice to clean up. hendrik at topoi.pooq.com wrote: > It seems relevant to out multiarchitecture system that Debian and Ubuntu > are currently also struggling to put together a multiarchitecture > system. > > Current thinking seems to be posted at > https://wiki.ubuntu.com/MultiarchSpec > > The stimulus for this work seems to be having 32-bit and 64-bit programs > coexist on the same AMD-64 system. But it also deals with questions > like MIPS systems having at least three different ABIs. > > Have a look. > > -- hendrik > > > From mika at async.caltech.edu Tue Jul 7 23:16:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Jul 2009 14:16:00 -0700 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> Message-ID: <200907072116.n67LG01G054470@taps.cs.caltech.edu> Going in the "other direction" it might be nice to have different derived directories for different compilers, e.g., CM3 and PM3, or different versions of CM3. Not something that is really necessary for anyone, I'm sure, but it seems like a flexible mechanism for "derived" directories might be able to handle that too... Mika "Rodney M. Bates" writes: >This may only be peripherally related, but since this discussion >has come up: > >I have long wished for a directory, neither src, nor the architecture >directory, for files that are mechanically generated but not >target dependent. I have an application where there are several >machine-generated files containing Modula-3 "source" code. > >It's "source code", in the sense that it is input to the compiler, but not >"source code", in the sense that it is not written by a human using >an editor. Some existing quake commands for instantiating generics >do similarly. Neither place is entirely appropriate for these files. > >I have gone through a series of kludgy ways of handling this. Right >now, I have them in a directory "derived", beside "src", with lines in >m3makefiles that look, e.g., like: > 'implementation("../derived/M3InitTokStrings")'. > >But the instantiating quake functions put generated source code in >the arch directory, and sometimes unnecessarily regenerate it. > >Just something that it would be nice to clean up. > >hendrik at topoi.pooq.com wrote: >> It seems relevant to out multiarchitecture system that Debian and Ubuntu >> are currently also struggling to put together a multiarchitecture >> system. >> >> Current thinking seems to be posted at >> https://wiki.ubuntu.com/MultiarchSpec >> >> The stimulus for this work seems to be having 32-bit and 64-bit programs >> coexist on the same AMD-64 system. But it also deals with questions >> like MIPS systems having at least three different ABIs. >> >> Have a look. >> >> -- hendrik >> >> >> From jay.krell at cornell.edu Tue Jul 7 23:48:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 21:48:47 +0000 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <200907072116.n67LG01G054470@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> <200907072116.n67LG01G054470@taps.cs.caltech.edu> Message-ID: Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are. The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages. So you could do export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here ./do-cm3-std.py buildship export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here ./do-cm3-std.py buildship etc. ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there. The "problem" is that compile/link don't. Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path. MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line. Then you'd just export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic. However you get stuck in the "what is the same? What is different?" dilemna. What if I want to not optimize just some particular code I am debugging? It should still go along with all the rest of the code. What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto. Probably the "hash" overridable from the command line. But you still want good defaults. I have not seen this automatic approach used much. But certainly the idea of one output root is good. Certainly the original authors were thinking this way, they just stopped way short. - Jay ---------------------------------------- > To: rodney.m.bates at cox.net > Date: Tue, 7 Jul 2009 14:16:00 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch) > > Going in the "other direction" it might be nice to have different > derived directories for different compilers, e.g., CM3 and PM3, or > different versions of CM3. > > Not something that is really necessary for anyone, I'm sure, but > it seems like a flexible mechanism for "derived" directories might > be able to handle that too... > > Mika > > "Rodney M. Bates" writes: >>This may only be peripherally related, but since this discussion >>has come up: >> >>I have long wished for a directory, neither src, nor the architecture >>directory, for files that are mechanically generated but not >>target dependent. I have an application where there are several >>machine-generated files containing Modula-3 "source" code. >> >>It's "source code", in the sense that it is input to the compiler, but not >>"source code", in the sense that it is not written by a human using >>an editor. Some existing quake commands for instantiating generics >>do similarly. Neither place is entirely appropriate for these files. >> >>I have gone through a series of kludgy ways of handling this. Right >>now, I have them in a directory "derived", beside "src", with lines in >>m3makefiles that look, e.g., like: >> 'implementation("../derived/M3InitTokStrings")'. >> >>But the instantiating quake functions put generated source code in >>the arch directory, and sometimes unnecessarily regenerate it. >> >>Just something that it would be nice to clean up. >> >>hendrik at topoi.pooq.com wrote: >>> It seems relevant to out multiarchitecture system that Debian and Ubuntu >>> are currently also struggling to put together a multiarchitecture >>> system. >>> >>> Current thinking seems to be posted at >>> https://wiki.ubuntu.com/MultiarchSpec >>> >>> The stimulus for this work seems to be having 32-bit and 64-bit programs >>> coexist on the same AMD-64 system. But it also deals with questions >>> like MIPS systems having at least three different ABIs. >>> >>> Have a look. >>> >>> -- hendrik >>> >>> >>> From jay.krell at cornell.edu Tue Jul 7 22:56:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 7 Jul 2009 13:56:05 -0700 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> Message-ID: I see the base contradiction is between custom install location, non root install, and Unix binary installs. Whenever I install binaries in Unix I have to be root and I get no choice of install location. Only when I build from source are both of these relaxed. Windows varies. Often I can chose install location and sometimes I don't have to be admin (but I always am). $origin is a way to address this, but relative locations remain fixed. - Jay (phone) On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: > I understand that the $ORIGIN use in library paths does not work > if we want to have hierarchical overrides for an arbitrary set of > package pools. We'll either have to use absolute paths or rely > on a correct (automatically computed?) LD_LIBRARY_PATH setting. > > How do $ORIGIN and LD_LIBRARY_PATH work together? Are there > consistently defined semantics on different systems? > > Could we use $ORIGIN just for the one global system installation, > and rely on absolute paths for all other pools? Of course we'd > loose the ability to just copy from one pool to another this way, > but that may not be that important. > > Anyway, we (at least I) won't work on it right now... > > Olaf > > Quoting Jay K : > >> >> Really, I understand, but there is a problem nobody seems to see. >> >> >> Let's say there are multiple pkg roots. >> >> >> Remember my question? It is very important. >> "How are the dependencies of an .so or executable found?" >> >> >> What if I install to /opt/cm3. >> You install to $HOME/cm3 -- no need for root! >> We have some root/bin/executable. >> It uses of course libm3core.so. >> >> >> I want to be able to copy it from machine to machine, probably >> without relinking it or running some tool over it. >> >> >> People want to install libm3core.so to different places on >> different machines. >> >> >> Does root/bin/executable refer >> to /opt/cm3/lib? >> or $HOME/cm3/lib? >> or $ORIGIN/../lib? >> or no directory and user sets LD_LIBRARY_PATH? >> I'm not even sure you can omit the directory. >> >> >> There is a basic contradiction here. >> $ORIGIN is good. $ORIGIN is bad. >> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >> Full paths are good. Full paths are bad. >> The ability to install to different places is good. The ability to >> install to different places is bad. >> >> >> You cannot have all of: >> ability to specify install location >> AND multiple package roots, where a package root is sparse >> AND if I install to a custom location, I don't have to set >> LD_LIBRARY_PATH >> >> >> Now, while I advocate(d) $ORIGIN and custom install locations and >> no need for LD_LIBRARY_PATH, that approach does devolve to >> everything being in the same directory, which also seems not great. >> >> >> The difference is often that you don't use $ORIGIN for "well known >> important stuff". >> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >> it always is, like /usr/lib or somesuch. You don't actually ever >> use a custom install for it. If you want to build your own, you >> are probably building your own entire system, and might use chroot >> as part of that. >> >> >> But where is the line between "my stuff" and "well known important >> stuff"? Where is the line between stuff that can be installed >> anywhere vs. stuff that must be installed to its "standard" location? >> >> >> - Jay > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Tue Jul 7 23:50:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Jul 2009 21:50:05 +0000 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <200907072116.n67LG01G054470@taps.cs.caltech.edu> References: Your message of "Tue, 07 Jul 2009 15:02:53 CDT." <4A53A9ED.8020908@cox.net> <200907072116.n67LG01G054470@taps.cs.caltech.edu> Message-ID: ps: ccache is something that kind of goes this automatic way, but for different reasons and not really applicable. It is looking for opportunistic identicalness and really striving for the strongest definition of identical. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; rodney.m.bates at cox.net > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Arch-independent derived files (Re: multiarch) > Date: Tue, 7 Jul 2009 21:48:47 +0000 > > > Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are. > > > The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages. > > > So you could do > > export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here > export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here > ./do-cm3-std.py buildship > > > export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here > export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here > ./do-cm3-std.py buildship > > etc. > > ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there. > > The "problem" is that compile/link don't. > > Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path. > > MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line. > > Then you'd just > export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic. > > However you get stuck in the "what is the same? What is different?" dilemna. > What if I want to not optimize just some particular code I am debugging? > It should still go along with all the rest of the code. > What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto. > > > Probably the "hash" overridable from the command line. > But you still want good defaults. > > > I have not seen this automatic approach used much. > But certainly the idea of one output root is good. > Certainly the original authors were thinking this way, they just stopped way short. > > > - Jay > > > > > > ---------------------------------------- >> To: rodney.m.bates at cox.net >> Date: Tue, 7 Jul 2009 14:16:00 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch) >> >> Going in the "other direction" it might be nice to have different >> derived directories for different compilers, e.g., CM3 and PM3, or >> different versions of CM3. >> >> Not something that is really necessary for anyone, I'm sure, but >> it seems like a flexible mechanism for "derived" directories might >> be able to handle that too... >> >> Mika >> >> "Rodney M. Bates" writes: >>>This may only be peripherally related, but since this discussion >>>has come up: >>> >>>I have long wished for a directory, neither src, nor the architecture >>>directory, for files that are mechanically generated but not >>>target dependent. I have an application where there are several >>>machine-generated files containing Modula-3 "source" code. >>> >>>It's "source code", in the sense that it is input to the compiler, but not >>>"source code", in the sense that it is not written by a human using >>>an editor. Some existing quake commands for instantiating generics >>>do similarly. Neither place is entirely appropriate for these files. >>> >>>I have gone through a series of kludgy ways of handling this. Right >>>now, I have them in a directory "derived", beside "src", with lines in >>>m3makefiles that look, e.g., like: >>> 'implementation("../derived/M3InitTokStrings")'. >>> >>>But the instantiating quake functions put generated source code in >>>the arch directory, and sometimes unnecessarily regenerate it. >>> >>>Just something that it would be nice to clean up. >>> >>>hendrik at topoi.pooq.com wrote: >>>> It seems relevant to out multiarchitecture system that Debian and Ubuntu >>>> are currently also struggling to put together a multiarchitecture >>>> system. >>>> >>>> Current thinking seems to be posted at >>>> https://wiki.ubuntu.com/MultiarchSpec >>>> >>>> The stimulus for this work seems to be having 32-bit and 64-bit programs >>>> coexist on the same AMD-64 system. But it also deals with questions >>>> like MIPS systems having at least three different ABIs. >>>> >>>> Have a look. >>>> >>>> -- hendrik >>>> >>>> >>>> From jay.krell at cornell.edu Tue Jul 7 22:38:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 7 Jul 2009 13:38:48 -0700 Subject: [M3devel] Arch-independent derived files (Re: multiarch) In-Reply-To: <4A53A9ED.8020908@cox.net> References: <20090703231254.GA25415@topoi.pooq.com> <4A53A9ED.8020908@cox.net> Message-ID: I have seen systems head that way, only to abandon it, for the sake of consistency and simplicity -- outputs all in one more known place, and for concurrency -- build multiple architectures without them stomping on each other. Are the files large or slow to be generated? I am on the fence. I like identifying what is the same and removing duplication. But if it is automated and fast, less motivation. Considering more of the system, we do parse identical .i3 files per- platform. The middle end work is also almost the same for every platform. But judging from the overall NT386 speed, this is all very fast. - Jay (phone) On Jul 7, 2009, at 1:02 PM, "Rodney M. Bates" wrote: > This may only be peripherally related, but since this discussion > has come up: > > I have long wished for a directory, neither src, nor the architecture > directory, for files that are mechanically generated but not > target dependent. I have an application where there are several > machine-generated files containing Modula-3 "source" code. > > It's "source code", in the sense that it is input to the compiler, > but not > "source code", in the sense that it is not written by a human using > an editor. Some existing quake commands for instantiating generics > do similarly. Neither place is entirely appropriate for these files. > > I have gone through a series of kludgy ways of handling this. Right > now, I have them in a directory "derived", beside "src", with lines in > m3makefiles that look, e.g., like: > 'implementation("../derived/M3InitTokStrings")'. > > But the instantiating quake functions put generated source code in > the arch directory, and sometimes unnecessarily regenerate it. > > Just something that it would be nice to clean up. > > hendrik at topoi.pooq.com wrote: >> It seems relevant to out multiarchitecture system that Debian and >> Ubuntu are currently also struggling to put together a >> multiarchitecture system. >> >> Current thinking seems to be posted at >> https://wiki.ubuntu.com/MultiarchSpec >> >> The stimulus for this work seems to be having 32-bit and 64-bit >> programs coexist on the same AMD-64 system. But it also deals with >> questions like MIPS systems having at least three different ABIs. >> >> Have a look. >> >> -- hendrik >> >> >> > > From carson at taltos.org Fri Jul 10 01:15:51 2009 From: carson at taltos.org (Carson Gaspar) Date: Thu, 09 Jul 2009 16:15:51 -0700 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> Message-ID: <4A567A27.8080203@taltos.org> LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X) _usually_ overrides a compiled-in search path. I know it does on Linux, MacOS X, and Solaris. And yes, you can "omit the directory" on most flavours of UNIX (although not on MacOS X, which gets complicated). If you leave out rpath, only the system default locations (and LD_LIBRARY_PATH, if set) will be searched. My opinion: - The primary installation should be built using a relative RPATH only ($ORIGIN/../lib or whatever). That does imply flatening the installed namespace to something more traditional, or including symlinks (if you have /usr/local/m3/lib/libfoo.so and /usr/local/m3/my/sub/module/mybinary you'd need to symlink /usr/local/m3/my/sub/module/lib to ../../../lib, or symlink each .so.*). - If a user builds with an alternate root, it should include an absolute RPATH for the standard installed location. It may _also_ include a relative RPATH, if needed (module builds its own .so libs), which should come first. This allows: - The binary install to be moved between systems easily - Binary non-standard location modules to be moved to any location on systems that share the same standard install location. This is about as flexible as you can get on most platforms. Note that on MacOS X you can use install_name_tool to re-write library locations, as long as the original was built with enough padding (linked with -headerpad_max_install_names, or the new name is shorter). This will also be possible on newer versions of Solaris, but is not yet in Sol 10 (only in OpenSolaris). jay.krell at cornell.edu wrote: > I see the base contradiction is between custom install location, non > root install, and Unix binary installs. Whenever I install binaries in > Unix I have to be root and I get no choice of install location. Only > when I build from source are both of these relaxed. > > Windows varies. Often I can chose install location and sometimes I don't > have to be admin (but I always am). > > $origin is a way to address this, but relative locations remain fixed. > > - Jay (phone) > > On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: > >> I understand that the $ORIGIN use in library paths does not work >> if we want to have hierarchical overrides for an arbitrary set of >> package pools. We'll either have to use absolute paths or rely >> on a correct (automatically computed?) LD_LIBRARY_PATH setting. >> >> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there >> consistently defined semantics on different systems? >> >> Could we use $ORIGIN just for the one global system installation, >> and rely on absolute paths for all other pools? Of course we'd >> loose the ability to just copy from one pool to another this way, >> but that may not be that important. >> >> Anyway, we (at least I) won't work on it right now... >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Really, I understand, but there is a problem nobody seems to see. >>> >>> >>> Let's say there are multiple pkg roots. >>> >>> >>> Remember my question? It is very important. >>> "How are the dependencies of an .so or executable found?" >>> >>> >>> What if I install to /opt/cm3. >>> You install to $HOME/cm3 -- no need for root! >>> We have some root/bin/executable. >>> It uses of course libm3core.so. >>> >>> >>> I want to be able to copy it from machine to machine, probably >>> without relinking it or running some tool over it. >>> >>> >>> People want to install libm3core.so to different places on different >>> machines. >>> >>> >>> Does root/bin/executable refer >>> to /opt/cm3/lib? >>> or $HOME/cm3/lib? >>> or $ORIGIN/../lib? >>> or no directory and user sets LD_LIBRARY_PATH? >>> I'm not even sure you can omit the directory. >>> >>> >>> There is a basic contradiction here. >>> $ORIGIN is good. $ORIGIN is bad. >>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >>> Full paths are good. Full paths are bad. >>> The ability to install to different places is good. The ability to >>> install to different places is bad. >>> >>> >>> You cannot have all of: >>> ability to specify install location >>> AND multiple package roots, where a package root is sparse >>> AND if I install to a custom location, I don't have to set >>> LD_LIBRARY_PATH >>> >>> >>> Now, while I advocate(d) $ORIGIN and custom install locations and no >>> need for LD_LIBRARY_PATH, that approach does devolve to everything >>> being in the same directory, which also seems not great. >>> >>> >>> The difference is often that you don't use $ORIGIN for "well known >>> important stuff". >>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >>> it always is, like /usr/lib or somesuch. You don't actually ever use >>> a custom install for it. If you want to build your own, you are >>> probably building your own entire system, and might use chroot as >>> part of that. >>> >>> >>> But where is the line between "my stuff" and "well known important >>> stuff"? Where is the line between stuff that can be installed >>> anywhere vs. stuff that must be installed to its "standard" location? >>> >>> >>> - Jay >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 >> 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> From jay.krell at cornell.edu Fri Jul 10 03:36:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 10 Jul 2009 01:36:21 +0000 Subject: [M3devel] pkg roots/origin/ld_library_path In-Reply-To: <4A567A27.8080203@taltos.org> References: <20090707150545.hog90bxqbcwkks88@mail.elegosoft.com> <4A567A27.8080203@taltos.org> Message-ID: I think we very much agree. Which comes first, LD_LIBRARY_PATH or runpath? The default build uses both $ORIGIN/../lib and fullpath. Like you suggest. I forget the order. $ORIGIN first would be good I think. I'll check and make it so. There is an environment variable to suppress the fullpath. The existing "scripts" set it. You can find its name in the scripts and the config files. Something like CM3_PORTABLE_RUNPATH. I know environment variables are lame. The structure has already been flattened. It was always "available" flattened, but symlinked into the deep structure, which I believe largely defeated our current goals. Now there is just the flat structure and the deep structure is "gone" (well, two files removed out of each directory). I also put $ORIGIN alone in the runpath, without the ../lib, so you can further flatten lib into bin. I'm fairly sympathetic to that but I suspect not many other people are. ? I always reserve the maximum space on MacOSX (in the config files), having seen that stuff in the manpages and figuring "reserving the maximum" probably isn't too wasteful and is a nice item on the "flexibility checklist" (that is, something I'll probably never use, but if anyone wants it, sure, it's there). That way, "link upon install" can be "run that tool upon install". I had seen similar for Solaris but I forget the details, which you filled in. - Jay ---------------------------------------- > Date: Thu, 9 Jul 2009 16:15:51 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] pkg roots/origin/ld_library_path > > LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X) _usually_ overrides a > compiled-in search path. I know it does on Linux, MacOS X, and Solaris. > > And yes, you can "omit the directory" on most flavours of UNIX (although not on > MacOS X, which gets complicated). If you leave out rpath, only the system > default locations (and LD_LIBRARY_PATH, if set) will be searched. > > My opinion: > > - The primary installation should be built using a relative RPATH only > ($ORIGIN/../lib or whatever). That does imply flatening the installed namespace > to something more traditional, or including symlinks (if you have > /usr/local/m3/lib/libfoo.so and /usr/local/m3/my/sub/module/mybinary you'd need > to symlink /usr/local/m3/my/sub/module/lib to ../../../lib, or symlink each .so.*). > > - If a user builds with an alternate root, it should include an absolute RPATH > for the standard installed location. It may _also_ include a relative RPATH, if > needed (module builds its own .so libs), which should come first. > > This allows: > > - The binary install to be moved between systems easily > - Binary non-standard location modules to be moved to any location on systems > that share the same standard install location. > > This is about as flexible as you can get on most platforms. > > Note that on MacOS X you can use install_name_tool to re-write library > locations, as long as the original was built with enough padding (linked with > -headerpad_max_install_names, or the new name is shorter). This will also be > possible on newer versions of Solaris, but is not yet in Sol 10 (only in > OpenSolaris). > > > jay.krell at cornell.edu wrote: >> I see the base contradiction is between custom install location, non >> root install, and Unix binary installs. Whenever I install binaries in >> Unix I have to be root and I get no choice of install location. Only >> when I build from source are both of these relaxed. >> >> Windows varies. Often I can chose install location and sometimes I don't >> have to be admin (but I always am). >> >> $origin is a way to address this, but relative locations remain fixed. >> >> - Jay (phone) >> >> On Jul 7, 2009, at 6:05 AM, Olaf Wagner wrote: >> >>> I understand that the $ORIGIN use in library paths does not work >>> if we want to have hierarchical overrides for an arbitrary set of >>> package pools. We'll either have to use absolute paths or rely >>> on a correct (automatically computed?) LD_LIBRARY_PATH setting. >>> >>> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there >>> consistently defined semantics on different systems? >>> >>> Could we use $ORIGIN just for the one global system installation, >>> and rely on absolute paths for all other pools? Of course we'd >>> loose the ability to just copy from one pool to another this way, >>> but that may not be that important. >>> >>> Anyway, we (at least I) won't work on it right now... >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Really, I understand, but there is a problem nobody seems to see. >>>> >>>> >>>> Let's say there are multiple pkg roots. >>>> >>>> >>>> Remember my question? It is very important. >>>> "How are the dependencies of an .so or executable found?" >>>> >>>> >>>> What if I install to /opt/cm3. >>>> You install to $HOME/cm3 -- no need for root! >>>> We have some root/bin/executable. >>>> It uses of course libm3core.so. >>>> >>>> >>>> I want to be able to copy it from machine to machine, probably >>>> without relinking it or running some tool over it. >>>> >>>> >>>> People want to install libm3core.so to different places on different >>>> machines. >>>> >>>> >>>> Does root/bin/executable refer >>>> to /opt/cm3/lib? >>>> or $HOME/cm3/lib? >>>> or $ORIGIN/../lib? >>>> or no directory and user sets LD_LIBRARY_PATH? >>>> I'm not even sure you can omit the directory. >>>> >>>> >>>> There is a basic contradiction here. >>>> $ORIGIN is good. $ORIGIN is bad. >>>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad. >>>> Full paths are good. Full paths are bad. >>>> The ability to install to different places is good. The ability to >>>> install to different places is bad. >>>> >>>> >>>> You cannot have all of: >>>> ability to specify install location >>>> AND multiple package roots, where a package root is sparse >>>> AND if I install to a custom location, I don't have to set >>>> LD_LIBRARY_PATH >>>> >>>> >>>> Now, while I advocate(d) $ORIGIN and custom install locations and no >>>> need for LD_LIBRARY_PATH, that approach does devolve to everything >>>> being in the same directory, which also seems not great. >>>> >>>> >>>> The difference is often that you don't use $ORIGIN for "well known >>>> important stuff". >>>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where >>>> it always is, like /usr/lib or somesuch. You don't actually ever use >>>> a custom install for it. If you want to build your own, you are >>>> probably building your own entire system, and might use chroot as >>>> part of that. >>>> >>>> >>>> But where is the line between "my stuff" and "well known important >>>> stuff"? Where is the line between stuff that can be installed >>>> anywhere vs. stuff that must be installed to its "standard" location? >>>> >>>> >>>> - Jay >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 >>> 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> > > From wagner at elegosoft.com Sat Jul 11 12:47:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Jul 2009 12:47:44 +0200 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <255528.11130.qm@web56801.mail.re3.yahoo.com> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Hm, I'm afraid we may have a regression in the runtime/gc here. CVSup always worked without problems for me (and still is copying FreeBSD, CM3 and other repositories between various machines for me and Elego). Surely CVSup is doing no such thing as keeping all its files in memory. I haven't tried the version Jay put into the CM3 repo though. So I see three possibilities: o Jay introduced the problem in the CVSup sources when he adapted them to the current CM3 (low probability). o You've got a broken runtime / CM3 version (and current sources work). I'd guess you are using the current version though. o We've got a problem in our runtime code, perhaps -- but not necessarily -- the garbage collector. I'd suggest we rule out the second one and you reproduce the problem with a current source set (if not done yet). Then let's see what Jay and Antony have to say, as they did almost all the source changes in that area recently. Olaf Quoting Peter Eiserloh : > Hi Olaf, > > Well, I tried CVSup, and it started looking real good, until > it crashed, with a message from the M3 runtime, saying that > NEW could not allocate any memory. > > So I ran it a second time, and it got further, then crashed > again. > > So, a third time, but with "top" running in another window, > and sure enough cvsup, was allocating something like 1.2 GB > of data before it was crashing. This is bigger than the > CVS repository that it had already downloaded. > > I am thinking that cvsup is keeping the contents of every > file it downloaded in memory. If so, this is a problem. > > If it is properly removing references, then maybe the > garbage collector is failing. This would be a bigger > problem, but with our compiler's runtime library. > > Are other people noticing problems. Is it just me? > Am I the only one to attempt downloading the entire > CVS repository for CM3? Could you try it? > > > I sent an email to the email listed in cvsup's "about box" > (cvsup-bugs at polstra.com), but that failed. The email address > no longer works. > > peter at black:/data/modula-3/cm3 $ > debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup cvsupfile.cm3 > > *** > *** runtime error: > *** NEW() was unable to allocate more memory. > *** file "../src/runtime/common/RuntimeError.m3", line 63 > *** > > Aborted > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Olaf Wagner wrote: > >> From: Olaf Wagner >> Subject: Re: m3gdb and YACC >> To: "Peter Eiserloh" >> Date: Saturday, July 11, 2009, 2:49 AM >> Quoting Peter Eiserloh : >> >> > Hi Olaf, >> > >> > The import script (git-importcvs) internally uses >> cvsps, which >> > you may already have. >> > >> > Anyways, here is the first ten lines from a log file >> of an import >> > that I just started. >> > >> > >> > peter at black:~ $ head Import-cm3-20090708.log >> > Running cvsps... >> > WARNING: revision 1.1.3.1 of file >> m3-sys/m3cc/gcc/etc/make-stds.texi? on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >> > WARNING: revision 1.1.3.1 of file >> m3-sys/m3cc/gcc/.brik on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >> branch >> > WARNING: revision 1.1.3.1 of file? >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >> branch >> >> It looks like these files have a second vendor branch >> without a >> proper name. CVS does not cope well with multiple vendor >> branches >> (in fact it never really worked), but there won't be any >> valuable >> information in that branch I'm sure, so you can ignore it. >> >> > Later this weekend, I will attempt to use CVSup.? >> First, >> > I will have to find usable documentation, since I >> have >> > never used CVSup before. >> > >> > Do you have a script to use with CVSup to access the >> > CM3 CVS repo?? I am lasy. >> > >> > I use 'git' for all my current projects.? I used >> to use >> > CVS, and had started looking into using subversion >> (SVN), >> > I even purchased a couple books on SVN.? Then >> 'git' burst >> > upon the Linux world, and is gaining converts all over >> the >> > place. >> > >> > It really does provide a better work-flow.? The >> easy >> > creation of a branch is a given, it is git's ability >> > to do easy merges, which is gaining all the good >> reputation. >> > >> > Rather than get all evangelistic on you, as I am sure >> you >> > have already heard it many times already. >> > >> > Many businesses are moving to git.? The only >> problem some >> > enterprise companies are having is the ability to >> restrict >> > access of authorized users to only portions of the >> repository. >> > These types of problems don't effect open source >> software >> > development. >> > >> > Once I have a working 'git' repository for cm3, I will >> share >> > the technique, and maybe, start the foundations for a >> > transition from CVS, towards 'git'.? But I >> suggest a slow >> > process, with distinct stages.???At any >> stage we could stop, >> > or even revert. >> > >> > The problem is that once people start using git, they >> don''t >> > want to go back to using CVS, or any of the older >> methods. >> > Maybe that isn't so much of a problem after all. >> > >> > STAGE-1: Simple mirror of the CVS archive, >> periodically >> >? ? ? ? ? updated (say once >> every 6 hours).? Document on >> >? ? ? ? ? web site, as to how >> to clone, and update a git >> >? ? ? ? ? repository.? No >> uploads to git. >> > STAGE-2: Convert web page scripts to use git. >> > STAGE-3: Convert tinderbox. >> > STAGE-4: Uploads to git.? Install gitosis or >> similar server >> >? ? ? ? ? for git uploads. >> Document the upload process on web >> >? ? ? ? ? pages. >> > STAGE-5: CVS mirrors the git repo.? Uploads to >> git only. >> > STAGE-6: Move last of the CVS people, over to git. >> > STAGE-7: Remove CVS.? (optional) >> >> Let's see how far you get. Converting all the >> infrastructure (scripts >> and documentation) may be much more work than you imagine. >> And one >> we propose a special tool (be it git or svn or mercurial) >> there will >> start discussions on what is best and what we should do >> :-/ >> >> So offering an optional alternative access may be a good >> plan. >> The majority of users should agree that they want the >> change though. >> And we need to consider use of GUIs and Windows users, >> too. >> >> Olaf >> --Olaf Wagner -- elego Software Solutions GmbH >> ? ? ? ? ? ? >> ???Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, Germany >> phone: +49 30 23 45 86 96? mobile: +49 177 2345 >> 869? fax: +49 30 23 45 86 95 >> ???http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 11 17:19:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 11:19:52 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: I'd definitely need some way to reproduce the problem. Detailed instructions would be best. What platform are you running on? On 11 Jul 2009, at 06:47, Olaf Wagner wrote: > Hm, I'm afraid we may have a regression in the runtime/gc here. > CVSup always worked without problems for me (and still is copying > FreeBSD, CM3 and other repositories between various machines for > me and Elego). Surely CVSup is doing no such thing as keeping > all its files in memory. > > I haven't tried the version Jay put into the CM3 repo though. > So I see three possibilities: > > o Jay introduced the problem in the CVSup sources when he > adapted them to the current CM3 (low probability). > > o You've got a broken runtime / CM3 version (and current > sources work). I'd guess you are using the current version though. > > o We've got a problem in our runtime code, perhaps -- but not > necessarily -- the garbage collector. > > I'd suggest we rule out the second one and you reproduce the problem > with a current source set (if not done yet). Then let's see what Jay > and Antony have to say, as they did almost all the source changes > in that area recently. > > Olaf > > Quoting Peter Eiserloh : > >> Hi Olaf, >> >> Well, I tried CVSup, and it started looking real good, until >> it crashed, with a message from the M3 runtime, saying that >> NEW could not allocate any memory. >> >> So I ran it a second time, and it got further, then crashed >> again. >> >> So, a third time, but with "top" running in another window, >> and sure enough cvsup, was allocating something like 1.2 GB >> of data before it was crashing. This is bigger than the >> CVS repository that it had already downloaded. >> >> I am thinking that cvsup is keeping the contents of every >> file it downloaded in memory. If so, this is a problem. >> >> If it is properly removing references, then maybe the >> garbage collector is failing. This would be a bigger >> problem, but with our compiler's runtime library. >> >> Are other people noticing problems. Is it just me? >> Am I the only one to attempt downloading the entire >> CVS repository for CM3? Could you try it? >> >> >> I sent an email to the email listed in cvsup's "about box" >> (cvsup-bugs at polstra.com), but that failed. The email address >> no longer works. >> >> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/usr/ >> lib/cm3/bin/cvsup cvsupfile.cm3 >> >> *** >> *** runtime error: >> *** NEW() was unable to allocate more memory. >> *** file "../src/runtime/common/RuntimeError.m3", line 63 >> *** >> >> Aborted >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, Olaf Wagner wrote: >> >>> From: Olaf Wagner >>> Subject: Re: m3gdb and YACC >>> To: "Peter Eiserloh" >>> Date: Saturday, July 11, 2009, 2:49 AM >>> Quoting Peter Eiserloh : >>> >>> > Hi Olaf, >>> > >>> > The import script (git-importcvs) internally uses >>> cvsps, which >>> > you may already have. >>> > >>> > Anyways, here is the first ten lines from a log file >>> of an import >>> > that I just started. >>> > >>> > >>> > peter at black:~ $ head Import-cm3-20090708.log >>> > Running cvsps... >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/.brik on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>> branch >>> > WARNING: revision 1.1.3.1 of file >>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>> branch >>> >>> It looks like these files have a second vendor branch >>> without a >>> proper name. CVS does not cope well with multiple vendor >>> branches >>> (in fact it never really worked), but there won't be any >>> valuable >>> information in that branch I'm sure, so you can ignore it. >>> >>> > Later this weekend, I will attempt to use CVSup. >>> First, >>> > I will have to find usable documentation, since I >>> have >>> > never used CVSup before. >>> > >>> > Do you have a script to use with CVSup to access the >>> > CM3 CVS repo? I am lasy. >>> > >>> > I use 'git' for all my current projects. I used >>> to use >>> > CVS, and had started looking into using subversion >>> (SVN), >>> > I even purchased a couple books on SVN. Then >>> 'git' burst >>> > upon the Linux world, and is gaining converts all over >>> the >>> > place. >>> > >>> > It really does provide a better work-flow. The >>> easy >>> > creation of a branch is a given, it is git's ability >>> > to do easy merges, which is gaining all the good >>> reputation. >>> > >>> > Rather than get all evangelistic on you, as I am sure >>> you >>> > have already heard it many times already. >>> > >>> > Many businesses are moving to git. The only >>> problem some >>> > enterprise companies are having is the ability to >>> restrict >>> > access of authorized users to only portions of the >>> repository. >>> > These types of problems don't effect open source >>> software >>> > development. >>> > >>> > Once I have a working 'git' repository for cm3, I will >>> share >>> > the technique, and maybe, start the foundations for a >>> > transition from CVS, towards 'git'. But I >>> suggest a slow >>> > process, with distinct stages. At any >>> stage we could stop, >>> > or even revert. >>> > >>> > The problem is that once people start using git, they >>> don''t >>> > want to go back to using CVS, or any of the older >>> methods. >>> > Maybe that isn't so much of a problem after all. >>> > >>> > STAGE-1: Simple mirror of the CVS archive, >>> periodically >>> > updated (say once >>> every 6 hours). Document on >>> > web site, as to how >>> to clone, and update a git >>> > repository. No >>> uploads to git. >>> > STAGE-2: Convert web page scripts to use git. >>> > STAGE-3: Convert tinderbox. >>> > STAGE-4: Uploads to git. Install gitosis or >>> similar server >>> > for git uploads. >>> Document the upload process on web >>> > pages. >>> > STAGE-5: CVS mirrors the git repo. Uploads to >>> git only. >>> > STAGE-6: Move last of the CVS people, over to git. >>> > STAGE-7: Remove CVS. (optional) >>> >>> Let's see how far you get. Converting all the >>> infrastructure (scripts >>> and documentation) may be much more work than you imagine. >>> And one >>> we propose a special tool (be it git or svn or mercurial) >>> there will >>> start discussions on what is best and what we should do >>> :-/ >>> >>> So offering an optional alternative access may be a good >>> plan. >>> The majority of users should agree that they want the >>> change though. >>> And we need to consider use of GUIs and Windows users, >>> too. >>> >>> Olaf >>> --Olaf Wagner -- elego Software Solutions GmbH >>> >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>> Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>> 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | >>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>> USt-IdNr: DE163214194 >>> >>> >> >> >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 11 18:21:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 12:21:28 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: Weird. I've just noticed that the collector has been disabled in RTCollector.i3 (not sure why I did that, but it had something to do with Jay's changes to the locking code in ThreadPThread). It should definitely be reverted, but probably exposes some weirdness in Jay's mutex initialization code. Jay, can you help? On 11 Jul 2009, at 11:19, Tony Hosking wrote: > I'd definitely need some way to reproduce the problem. Detailed > instructions would be best. What platform are you running on? > > On 11 Jul 2009, at 06:47, Olaf Wagner wrote: > >> Hm, I'm afraid we may have a regression in the runtime/gc here. >> CVSup always worked without problems for me (and still is copying >> FreeBSD, CM3 and other repositories between various machines for >> me and Elego). Surely CVSup is doing no such thing as keeping >> all its files in memory. >> >> I haven't tried the version Jay put into the CM3 repo though. >> So I see three possibilities: >> >> o Jay introduced the problem in the CVSup sources when he >> adapted them to the current CM3 (low probability). >> >> o You've got a broken runtime / CM3 version (and current >> sources work). I'd guess you are using the current version though. >> >> o We've got a problem in our runtime code, perhaps -- but not >> necessarily -- the garbage collector. >> >> I'd suggest we rule out the second one and you reproduce the problem >> with a current source set (if not done yet). Then let's see what Jay >> and Antony have to say, as they did almost all the source changes >> in that area recently. >> >> Olaf >> >> Quoting Peter Eiserloh : >> >>> Hi Olaf, >>> >>> Well, I tried CVSup, and it started looking real good, until >>> it crashed, with a message from the M3 runtime, saying that >>> NEW could not allocate any memory. >>> >>> So I ran it a second time, and it got further, then crashed >>> again. >>> >>> So, a third time, but with "top" running in another window, >>> and sure enough cvsup, was allocating something like 1.2 GB >>> of data before it was crashing. This is bigger than the >>> CVS repository that it had already downloaded. >>> >>> I am thinking that cvsup is keeping the contents of every >>> file it downloaded in memory. If so, this is a problem. >>> >>> If it is properly removing references, then maybe the >>> garbage collector is failing. This would be a bigger >>> problem, but with our compiler's runtime library. >>> >>> Are other people noticing problems. Is it just me? >>> Am I the only one to attempt downloading the entire >>> CVS repository for CM3? Could you try it? >>> >>> >>> I sent an email to the email listed in cvsup's "about box" >>> (cvsup-bugs at polstra.com), but that failed. The email address >>> no longer works. >>> >>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>> >>> *** >>> *** runtime error: >>> *** NEW() was unable to allocate more memory. >>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>> *** >>> >>> Aborted >>> >>> Peter >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>> >>>> From: Olaf Wagner >>>> Subject: Re: m3gdb and YACC >>>> To: "Peter Eiserloh" >>>> Date: Saturday, July 11, 2009, 2:49 AM >>>> Quoting Peter Eiserloh : >>>> >>>> > Hi Olaf, >>>> > >>>> > The import script (git-importcvs) internally uses >>>> cvsps, which >>>> > you may already have. >>>> > >>>> > Anyways, here is the first ten lines from a log file >>>> of an import >>>> > that I just started. >>>> > >>>> > >>>> > peter at black:~ $ head Import-cm3-20090708.log >>>> > Running cvsps... >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>> branch >>>> > WARNING: revision 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>> branch >>>> >>>> It looks like these files have a second vendor branch >>>> without a >>>> proper name. CVS does not cope well with multiple vendor >>>> branches >>>> (in fact it never really worked), but there won't be any >>>> valuable >>>> information in that branch I'm sure, so you can ignore it. >>>> >>>> > Later this weekend, I will attempt to use CVSup. >>>> First, >>>> > I will have to find usable documentation, since I >>>> have >>>> > never used CVSup before. >>>> > >>>> > Do you have a script to use with CVSup to access the >>>> > CM3 CVS repo? I am lasy. >>>> > >>>> > I use 'git' for all my current projects. I used >>>> to use >>>> > CVS, and had started looking into using subversion >>>> (SVN), >>>> > I even purchased a couple books on SVN. Then >>>> 'git' burst >>>> > upon the Linux world, and is gaining converts all over >>>> the >>>> > place. >>>> > >>>> > It really does provide a better work-flow. The >>>> easy >>>> > creation of a branch is a given, it is git's ability >>>> > to do easy merges, which is gaining all the good >>>> reputation. >>>> > >>>> > Rather than get all evangelistic on you, as I am sure >>>> you >>>> > have already heard it many times already. >>>> > >>>> > Many businesses are moving to git. The only >>>> problem some >>>> > enterprise companies are having is the ability to >>>> restrict >>>> > access of authorized users to only portions of the >>>> repository. >>>> > These types of problems don't effect open source >>>> software >>>> > development. >>>> > >>>> > Once I have a working 'git' repository for cm3, I will >>>> share >>>> > the technique, and maybe, start the foundations for a >>>> > transition from CVS, towards 'git'. But I >>>> suggest a slow >>>> > process, with distinct stages. At any >>>> stage we could stop, >>>> > or even revert. >>>> > >>>> > The problem is that once people start using git, they >>>> don''t >>>> > want to go back to using CVS, or any of the older >>>> methods. >>>> > Maybe that isn't so much of a problem after all. >>>> > >>>> > STAGE-1: Simple mirror of the CVS archive, >>>> periodically >>>> > updated (say once >>>> every 6 hours). Document on >>>> > web site, as to how >>>> to clone, and update a git >>>> > repository. No >>>> uploads to git. >>>> > STAGE-2: Convert web page scripts to use git. >>>> > STAGE-3: Convert tinderbox. >>>> > STAGE-4: Uploads to git. Install gitosis or >>>> similar server >>>> > for git uploads. >>>> Document the upload process on web >>>> > pages. >>>> > STAGE-5: CVS mirrors the git repo. Uploads to >>>> git only. >>>> > STAGE-6: Move last of the CVS people, over to git. >>>> > STAGE-7: Remove CVS. (optional) >>>> >>>> Let's see how far you get. Converting all the >>>> infrastructure (scripts >>>> and documentation) may be much more work than you imagine. >>>> And one >>>> we propose a special tool (be it git or svn or mercurial) >>>> there will >>>> start discussions on what is best and what we should do >>>> :-/ >>>> >>>> So offering an optional alternative access may be a good >>>> plan. >>>> The majority of users should agree that they want the >>>> change though. >>>> And we need to consider use of GUIs and Windows users, >>>> too. >>>> >>>> Olaf >>>> --Olaf Wagner -- elego Software Solutions GmbH >>>> >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>> Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>> 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>> >>> >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 11 19:12:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 13:12:19 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> Message-ID: <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> Not sure how it happened, but the collector was turned off by default. It works for me now with the latest updates. On 11 Jul 2009, at 12:21, Tony Hosking wrote: > Weird. I've just noticed that the collector has been disabled in > RTCollector.i3 (not sure why I did that, but it had something to do > with Jay's changes to the locking code in ThreadPThread). It should > definitely be reverted, but probably exposes some weirdness in Jay's > mutex initialization code. Jay, can you help? > > > On 11 Jul 2009, at 11:19, Tony Hosking wrote: > >> I'd definitely need some way to reproduce the problem. Detailed >> instructions would be best. What platform are you running on? >> >> On 11 Jul 2009, at 06:47, Olaf Wagner wrote: >> >>> Hm, I'm afraid we may have a regression in the runtime/gc here. >>> CVSup always worked without problems for me (and still is copying >>> FreeBSD, CM3 and other repositories between various machines for >>> me and Elego). Surely CVSup is doing no such thing as keeping >>> all its files in memory. >>> >>> I haven't tried the version Jay put into the CM3 repo though. >>> So I see three possibilities: >>> >>> o Jay introduced the problem in the CVSup sources when he >>> adapted them to the current CM3 (low probability). >>> >>> o You've got a broken runtime / CM3 version (and current >>> sources work). I'd guess you are using the current version though. >>> >>> o We've got a problem in our runtime code, perhaps -- but not >>> necessarily -- the garbage collector. >>> >>> I'd suggest we rule out the second one and you reproduce the problem >>> with a current source set (if not done yet). Then let's see what Jay >>> and Antony have to say, as they did almost all the source changes >>> in that area recently. >>> >>> Olaf >>> >>> Quoting Peter Eiserloh : >>> >>>> Hi Olaf, >>>> >>>> Well, I tried CVSup, and it started looking real good, until >>>> it crashed, with a message from the M3 runtime, saying that >>>> NEW could not allocate any memory. >>>> >>>> So I ran it a second time, and it got further, then crashed >>>> again. >>>> >>>> So, a third time, but with "top" running in another window, >>>> and sure enough cvsup, was allocating something like 1.2 GB >>>> of data before it was crashing. This is bigger than the >>>> CVS repository that it had already downloaded. >>>> >>>> I am thinking that cvsup is keeping the contents of every >>>> file it downloaded in memory. If so, this is a problem. >>>> >>>> If it is properly removing references, then maybe the >>>> garbage collector is failing. This would be a bigger >>>> problem, but with our compiler's runtime library. >>>> >>>> Are other people noticing problems. Is it just me? >>>> Am I the only one to attempt downloading the entire >>>> CVS repository for CM3? Could you try it? >>>> >>>> >>>> I sent an email to the email listed in cvsup's "about box" >>>> (cvsup-bugs at polstra.com), but that failed. The email address >>>> no longer works. >>>> >>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>>> >>>> *** >>>> *** runtime error: >>>> *** NEW() was unable to allocate more memory. >>>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>>> *** >>>> >>>> Aborted >>>> >>>> Peter >>>> >>>> >>>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh | >>>> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>>> >>>>> From: Olaf Wagner >>>>> Subject: Re: m3gdb and YACC >>>>> To: "Peter Eiserloh" >>>>> Date: Saturday, July 11, 2009, 2:49 AM >>>>> Quoting Peter Eiserloh : >>>>> >>>>> > Hi Olaf, >>>>> > >>>>> > The import script (git-importcvs) internally uses >>>>> cvsps, which >>>>> > you may already have. >>>>> > >>>>> > Anyways, here is the first ten lines from a log file >>>>> of an import >>>>> > that I just started. >>>>> > >>>>> > >>>>> > peter at black:~ $ head Import-cm3-20090708.log >>>>> > Running cvsps... >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>>> branch >>>>> > WARNING: revision 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>>> branch >>>>> >>>>> It looks like these files have a second vendor branch >>>>> without a >>>>> proper name. CVS does not cope well with multiple vendor >>>>> branches >>>>> (in fact it never really worked), but there won't be any >>>>> valuable >>>>> information in that branch I'm sure, so you can ignore it. >>>>> >>>>> > Later this weekend, I will attempt to use CVSup. >>>>> First, >>>>> > I will have to find usable documentation, since I >>>>> have >>>>> > never used CVSup before. >>>>> > >>>>> > Do you have a script to use with CVSup to access the >>>>> > CM3 CVS repo? I am lasy. >>>>> > >>>>> > I use 'git' for all my current projects. I used >>>>> to use >>>>> > CVS, and had started looking into using subversion >>>>> (SVN), >>>>> > I even purchased a couple books on SVN. Then >>>>> 'git' burst >>>>> > upon the Linux world, and is gaining converts all over >>>>> the >>>>> > place. >>>>> > >>>>> > It really does provide a better work-flow. The >>>>> easy >>>>> > creation of a branch is a given, it is git's ability >>>>> > to do easy merges, which is gaining all the good >>>>> reputation. >>>>> > >>>>> > Rather than get all evangelistic on you, as I am sure >>>>> you >>>>> > have already heard it many times already. >>>>> > >>>>> > Many businesses are moving to git. The only >>>>> problem some >>>>> > enterprise companies are having is the ability to >>>>> restrict >>>>> > access of authorized users to only portions of the >>>>> repository. >>>>> > These types of problems don't effect open source >>>>> software >>>>> > development. >>>>> > >>>>> > Once I have a working 'git' repository for cm3, I will >>>>> share >>>>> > the technique, and maybe, start the foundations for a >>>>> > transition from CVS, towards 'git'. But I >>>>> suggest a slow >>>>> > process, with distinct stages. At any >>>>> stage we could stop, >>>>> > or even revert. >>>>> > >>>>> > The problem is that once people start using git, they >>>>> don''t >>>>> > want to go back to using CVS, or any of the older >>>>> methods. >>>>> > Maybe that isn't so much of a problem after all. >>>>> > >>>>> > STAGE-1: Simple mirror of the CVS archive, >>>>> periodically >>>>> > updated (say once >>>>> every 6 hours). Document on >>>>> > web site, as to how >>>>> to clone, and update a git >>>>> > repository. No >>>>> uploads to git. >>>>> > STAGE-2: Convert web page scripts to use git. >>>>> > STAGE-3: Convert tinderbox. >>>>> > STAGE-4: Uploads to git. Install gitosis or >>>>> similar server >>>>> > for git uploads. >>>>> Document the upload process on web >>>>> > pages. >>>>> > STAGE-5: CVS mirrors the git repo. Uploads to >>>>> git only. >>>>> > STAGE-6: Move last of the CVS people, over to git. >>>>> > STAGE-7: Remove CVS. (optional) >>>>> >>>>> Let's see how far you get. Converting all the >>>>> infrastructure (scripts >>>>> and documentation) may be much more work than you imagine. >>>>> And one >>>>> we propose a special tool (be it git or svn or mercurial) >>>>> there will >>>>> start discussions on what is best and what we should do >>>>> :-/ >>>>> >>>>> So offering an optional alternative access may be a good >>>>> plan. >>>>> The majority of users should agree that they want the >>>>> change though. >>>>> And we need to consider use of GUIs and Windows users, >>>>> too. >>>>> >>>>> Olaf >>>>> --Olaf Wagner -- elego Software Solutions GmbH >>>>> >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>>> Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>>> 869 fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | >>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sat Jul 11 22:10:29 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 11 Jul 2009 13:10:29 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <756206.45056.qm@web56807.mail.re3.yahoo.com> Hi Tony, Architecture: AMD64_LINUX. Code base: 20090628. I am untarring 20090710 right now, and will rebuild the CM3 against it using the standard scripts/do-cm3-std.sh I don't expect any difference in behavior though as that is pretty much what my Makefile does anyways. Okay, I can also try this on my old Macintosh (PPC_DARWIN). Are there any additional diagnostics that I can turn on in the runtime? Something simple may help like when NEW complains, printing out: o the size of memory currently allocated, o the current number of allocations, o the total number of allocations performed, o the number of garbage collection runs performed, and o the number of objects reclaimed by the garbage collector, and so forth. This may be difficult since we just failed to allocate, memory, the diagnostics may not have the ability to format strings for output. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 7/11/09, Tony Hosking wrote: > From: Tony Hosking > Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC > To: "Olaf Wagner" > Cc: "Peter Eiserloh" , m3devel at elegosoft.com > Date: Saturday, July 11, 2009, 8:19 AM > I'd definitely need some way to reproduce the > problem. ?Detailed instructions would be best. > ?What platform are you running > on? > On 11 Jul 2009, at 06:47, Olaf > Wagner > wrote: > Hm, I'm afraid we may have a regression > in the runtime/gc here. > CVSup always worked without problems for me (and still is > copying > FreeBSD, CM3 and other repositories between various > machines for > me and Elego). Surely CVSup is doing no such thing as > keeping > all its files in memory. > > I haven't tried the version Jay put into the CM3 repo > though. > So I see three possibilities: > > o Jay introduced the problem in the CVSup sources when he > ??adapted them to the current CM3 (low > probability). > > o You've got a broken runtime / CM3 version (and > current > ??sources work). I'd guess you are using the > current version though. > > o We've got a problem in our runtime code, perhaps -- > but not > ??necessarily -- the garbage collector. > > I'd suggest we rule out the second one and you > reproduce the problem > with a current source set (if not done yet). Then let's > see what Jay > and Antony have to say, as they did almost all the source > changes > in that area recently. > > Olaf > > Quoting Peter Eiserloh : > > Hi Olaf, > > Well, I tried CVSup, > and it started looking real good, until > it crashed, with a > message from the M3 runtime, saying that > NEW could not allocate > any memory. > > So I ran it a second > time, and it got further, then crashed > again. > > So, a third time, but > with "top" running in another window, > and sure enough cvsup, > was allocating something like 1.2 GB > of data before it was > crashing. ?This is bigger than the > CVS repository that it > had already downloaded. > > I am thinking that > cvsup is keeping the contents of every > file it downloaded in > memory. ?If so, this is a problem. > > If it is properly > removing references, then maybe the > garbage collector is > failing. ?This would be a bigger > problem, but with our > compiler's runtime library. > > Are other people > noticing problems. ?Is it just me? > Am I the only one to > attempt downloading the entire > CVS repository for > CM3? ?Could you try it? > > > I sent an email to the > email listed in cvsup's "about box" > (cvsup-bugs at polstra.com), > but that failed. ?The email address > no longer works. > > peter at black:/data/modula-3/cm3 $ > ?debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup > cvsupfile.cm3 > > *** > *** runtime error: > *** > ???NEW() was unable to allocate more memory. > *** > ???file > "../src/runtime/common/RuntimeError.m3", line 63 > *** > > Aborted > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > ?????????????????????????????????????| > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, > Olaf Wagner > wrote: > > From: Olaf Wagner > Subject: Re: m3gdb and > YACC > To: "Peter > Eiserloh" > Date: Saturday, July 11, > 2009, 2:49 AM > Quoting Peter Eiserloh > : > > > Hi Olaf, > > > > The import script > (git-importcvs) internally uses > cvsps, which > > you may already > have. > > > > Anyways, here is > the first ten lines from a log file > of an import > > that I just > started. > > > > > > peter at black:~ $ > head Import-cm3-20090708.log > > Running cvsps... > > WARNING: revision > 1.1.3.1 of file > m3-sys/m3cc/gcc/etc/make-stds.texi? on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on > unnamed branch > > WARNING: revision > 1.1.3.1 of file > m3-sys/m3cc/gcc/.brik on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on > unnamed branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on > unnamed > branch > > WARNING: revision > 1.1.3.1 of file? > m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on > unnamed > branch > > It looks like these > files have a second vendor branch > without a > proper name. CVS does > not cope well with multiple vendor > branches > (in fact it never really > worked), but there won't be any > valuable > information in that > branch I'm sure, so you can ignore it. > > > Later this weekend, > I will attempt to use CVSup.? > First, > > I will have to find > usable documentation, since I > have > > never used CVSup > before. > > > > Do you have a > script to use with CVSup to access the > > CM3 CVS repo?? > I am lasy. > > > > I use 'git' > for all my current projects.? I used > to use > > CVS, and had > started looking into using subversion > (SVN), > > I even purchased a > couple books on SVN.? Then > 'git' burst > > upon the Linux > world, and is gaining converts all over > the > > place. > > > > It really does > provide a better work-flow.? The > easy > > creation of a > branch is a given, it is git's ability > > to do easy merges, > which is gaining all the good > reputation. > > > > Rather than get all > evangelistic on you, as I am sure > you > > have already heard > it many times already. > > > > Many businesses are > moving to git.? The only > problem some > > enterprise > companies are having is the ability to > restrict > > access of > authorized users to only portions of the > repository. > > These types of > problems don't effect open source > software > > development. > > > > Once I have a > working 'git' repository for cm3, I will > share > > the technique, and > maybe, start the foundations for a > > transition from > CVS, towards 'git'.? But I > suggest a slow > > process, with > distinct stages.???At any > stage we could stop, > > or even revert. > > > > The problem is that > once people start using git, they > don''t > > want to go back to > using CVS, or any of the older > methods. > > Maybe that > isn't so much of a problem after all. > > > > STAGE-1: Simple > mirror of the CVS archive, > periodically > >? ? ? > ? ? updated (say once > every 6 hours).? > Document on > >? ? ? > ? ? web site, as to how > to clone, and update a > git > >? ? ? > ? ? repository.? No > uploads to git. > > STAGE-2: Convert > web page scripts to use git. > > STAGE-3: Convert > tinderbox. > > STAGE-4: Uploads to > git.? Install gitosis or > similar server > >? ? ? > ? ? for git uploads. > Document the upload > process on web > >? ? ? > ? ? pages. > > STAGE-5: CVS > mirrors the git repo.? Uploads to > git only. > > STAGE-6: Move last > of the CVS people, over to git. > > STAGE-7: Remove > CVS.? (optional) > > Let's see how far > you get. Converting all the > infrastructure (scripts > and documentation) may > be much more work than you imagine. > And one > we propose a special > tool (be it git or svn or mercurial) > there will > start discussions on > what is best and what we should do > :-/ > > So offering an optional > alternative access may be a good > plan. > The majority of users > should agree that they want the > change though. > And we need to consider > use of GUIs and Windows users, > too. > > Olaf > --Olaf Wagner -- elego > Software Solutions GmbH > ? ? ? > ? ? ? > ???Gustav-Meyer-Allee 25 / > Geb?ude 12, 13355 > Berlin, Germany > phone: +49 30 23 45 86 > 96? mobile: +49 177 2345 > 869? fax: +49 30 23 > 45 86 95 > ???http://www.elegosoft.com > | > Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > Handelregister: > Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > > ??????????????Gustav-Meyer-Allee > 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 ?mobile: +49 177 2345 869 > ?fax: +49 30 23 45 86 95 > ??http://www.elegosoft.com > | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > From wagner at elegosoft.com Sat Jul 11 23:16:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Jul 2009 23:16:51 +0200 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> References: <255528.11130.qm@web56801.mail.re3.yahoo.com> <20090711124744.yj2o0p2jwo4csgww@mail.elegosoft.com> <507C589B-8D37-4EBB-A8B0-7DE269EED585@cs.purdue.edu> Message-ID: <20090711231651.tvmtsb7s0004g0kk@mail.elegosoft.com> Quoting Tony Hosking : > Not sure how it happened, but the collector was turned off by default. > It works for me now with the latest updates. Great, thanks for the quick check and help. I assume this will resolve Peter's problems... Olaf > On 11 Jul 2009, at 12:21, Tony Hosking wrote: > >> Weird. I've just noticed that the collector has been disabled in >> RTCollector.i3 (not sure why I did that, but it had something to do >> with Jay's changes to the locking code in ThreadPThread). It >> should definitely be reverted, but probably exposes some weirdness >> in Jay's mutex initialization code. Jay, can you help? >> >> >> On 11 Jul 2009, at 11:19, Tony Hosking wrote: >> >>> I'd definitely need some way to reproduce the problem. Detailed >>> instructions would be best. What platform are you running on? >>> >>> On 11 Jul 2009, at 06:47, Olaf Wagner wrote: >>> >>>> Hm, I'm afraid we may have a regression in the runtime/gc here. >>>> CVSup always worked without problems for me (and still is copying >>>> FreeBSD, CM3 and other repositories between various machines for >>>> me and Elego). Surely CVSup is doing no such thing as keeping >>>> all its files in memory. >>>> >>>> I haven't tried the version Jay put into the CM3 repo though. >>>> So I see three possibilities: >>>> >>>> o Jay introduced the problem in the CVSup sources when he >>>> adapted them to the current CM3 (low probability). >>>> >>>> o You've got a broken runtime / CM3 version (and current >>>> sources work). I'd guess you are using the current version though. >>>> >>>> o We've got a problem in our runtime code, perhaps -- but not >>>> necessarily -- the garbage collector. >>>> >>>> I'd suggest we rule out the second one and you reproduce the problem >>>> with a current source set (if not done yet). Then let's see what Jay >>>> and Antony have to say, as they did almost all the source changes >>>> in that area recently. >>>> >>>> Olaf >>>> >>>> Quoting Peter Eiserloh : >>>> >>>>> Hi Olaf, >>>>> >>>>> Well, I tried CVSup, and it started looking real good, until >>>>> it crashed, with a message from the M3 runtime, saying that >>>>> NEW could not allocate any memory. >>>>> >>>>> So I ran it a second time, and it got further, then crashed >>>>> again. >>>>> >>>>> So, a third time, but with "top" running in another window, >>>>> and sure enough cvsup, was allocating something like 1.2 GB >>>>> of data before it was crashing. This is bigger than the >>>>> CVS repository that it had already downloaded. >>>>> >>>>> I am thinking that cvsup is keeping the contents of every >>>>> file it downloaded in memory. If so, this is a problem. >>>>> >>>>> If it is properly removing references, then maybe the >>>>> garbage collector is failing. This would be a bigger >>>>> problem, but with our compiler's runtime library. >>>>> >>>>> Are other people noticing problems. Is it just me? >>>>> Am I the only one to attempt downloading the entire >>>>> CVS repository for CM3? Could you try it? >>>>> >>>>> >>>>> I sent an email to the email listed in cvsup's "about box" >>>>> (cvsup-bugs at polstra.com), but that failed. The email address >>>>> no longer works. >>>>> >>>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/ >>>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3 >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** NEW() was unable to allocate more memory. >>>>> *** file "../src/runtime/common/RuntimeError.m3", line 63 >>>>> *** >>>>> >>>>> Aborted >>>>> >>>>> Peter >>>>> >>>>> >>>>> +--------------------------------------------------------+ >>>>> | Peter P. Eiserloh | >>>>> +--------------------------------------------------------+ >>>>> >>>>> >>>>> --- On Sat, 7/11/09, Olaf Wagner wrote: >>>>> >>>>>> From: Olaf Wagner >>>>>> Subject: Re: m3gdb and YACC >>>>>> To: "Peter Eiserloh" >>>>>> Date: Saturday, July 11, 2009, 2:49 AM >>>>>> Quoting Peter Eiserloh : >>>>>> >>>>>>> Hi Olaf, >>>>>>> >>>>>>> The import script (git-importcvs) internally uses >>>>>> cvsps, which >>>>>>> you may already have. >>>>>>> >>>>>>> Anyways, here is the first ten lines from a log file >>>>>> of an import >>>>>>> that I just started. >>>>>>> >>>>>>> >>>>>>> peter at black:~ $ head Import-cm3-20090708.log >>>>>>> Running cvsps... >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/.brik on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed >>>>>> branch >>>>>>> WARNING: revision 1.1.3.1 of file >>>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed >>>>>> branch >>>>>> >>>>>> It looks like these files have a second vendor branch >>>>>> without a >>>>>> proper name. CVS does not cope well with multiple vendor >>>>>> branches >>>>>> (in fact it never really worked), but there won't be any >>>>>> valuable >>>>>> information in that branch I'm sure, so you can ignore it. >>>>>> >>>>>>> Later this weekend, I will attempt to use CVSup. >>>>>> First, >>>>>>> I will have to find usable documentation, since I >>>>>> have >>>>>>> never used CVSup before. >>>>>>> >>>>>>> Do you have a script to use with CVSup to access the >>>>>>> CM3 CVS repo? I am lasy. >>>>>>> >>>>>>> I use 'git' for all my current projects. I used >>>>>> to use >>>>>>> CVS, and had started looking into using subversion >>>>>> (SVN), >>>>>>> I even purchased a couple books on SVN. Then >>>>>> 'git' burst >>>>>>> upon the Linux world, and is gaining converts all over >>>>>> the >>>>>>> place. >>>>>>> >>>>>>> It really does provide a better work-flow. The >>>>>> easy >>>>>>> creation of a branch is a given, it is git's ability >>>>>>> to do easy merges, which is gaining all the good >>>>>> reputation. >>>>>>> >>>>>>> Rather than get all evangelistic on you, as I am sure >>>>>> you >>>>>>> have already heard it many times already. >>>>>>> >>>>>>> Many businesses are moving to git. The only >>>>>> problem some >>>>>>> enterprise companies are having is the ability to >>>>>> restrict >>>>>>> access of authorized users to only portions of the >>>>>> repository. >>>>>>> These types of problems don't effect open source >>>>>> software >>>>>>> development. >>>>>>> >>>>>>> Once I have a working 'git' repository for cm3, I will >>>>>> share >>>>>>> the technique, and maybe, start the foundations for a >>>>>>> transition from CVS, towards 'git'. But I >>>>>> suggest a slow >>>>>>> process, with distinct stages. At any >>>>>> stage we could stop, >>>>>>> or even revert. >>>>>>> >>>>>>> The problem is that once people start using git, they >>>>>> don''t >>>>>>> want to go back to using CVS, or any of the older >>>>>> methods. >>>>>>> Maybe that isn't so much of a problem after all. >>>>>>> >>>>>>> STAGE-1: Simple mirror of the CVS archive, >>>>>> periodically >>>>>>> updated (say once >>>>>> every 6 hours). Document on >>>>>>> web site, as to how >>>>>> to clone, and update a git >>>>>>> repository. No >>>>>> uploads to git. >>>>>>> STAGE-2: Convert web page scripts to use git. >>>>>>> STAGE-3: Convert tinderbox. >>>>>>> STAGE-4: Uploads to git. Install gitosis or >>>>>> similar server >>>>>>> for git uploads. >>>>>> Document the upload process on web >>>>>>> pages. >>>>>>> STAGE-5: CVS mirrors the git repo. Uploads to >>>>>> git only. >>>>>>> STAGE-6: Move last of the CVS people, over to git. >>>>>>> STAGE-7: Remove CVS. (optional) >>>>>> >>>>>> Let's see how far you get. Converting all the >>>>>> infrastructure (scripts >>>>>> and documentation) may be much more work than you imagine. >>>>>> And one >>>>>> we propose a special tool (be it git or svn or mercurial) >>>>>> there will >>>>>> start discussions on what is best and what we should do >>>>>> :-/ >>>>>> >>>>>> So offering an optional alternative access may be a good >>>>>> plan. >>>>>> The majority of users should agree that they want the >>>>>> change though. >>>>>> And we need to consider use of GUIs and Windows users, >>>>>> too. >>>>>> >>>>>> Olaf >>>>>> --Olaf Wagner -- elego Software Solutions GmbH >>>>>> >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >>>>>> Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >>>>>> 869 fax: +49 30 23 45 86 95 >>>>>> http://www.elegosoft.com | >>>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >>>>>> USt-IdNr: DE163214194 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>> 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 11 23:31:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Jul 2009 17:31:54 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <756206.45056.qm@web56807.mail.re3.yahoo.com> References: <756206.45056.qm@web56807.mail.re3.yahoo.com> Message-ID: <74B566D0-7F39-44B4-BE95-2A743DAB639F@cs.purdue.edu> Please try my recent commits from earlier to day. On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: > > Hi Tony, > > Architecture: AMD64_LINUX. > Code base: 20090628. > > I am untarring 20090710 right now, and will rebuild the > CM3 against it using the standard scripts/do-cm3-std.sh > > I don't expect any difference in behavior though as that > is pretty much what my Makefile does anyways. > > Okay, I can also try this on my old Macintosh (PPC_DARWIN). > > > Are there any additional diagnostics that I can turn on > in the runtime? Something simple may help like when NEW > complains, printing out: > o the size of memory currently allocated, > o the current number of allocations, > o the total number of allocations performed, > o the number of garbage collection runs performed, and > o the number of objects reclaimed by the garbage collector, > and so forth. > > This may be difficult since we just failed to allocate, > memory, the diagnostics may not have the ability to > format strings for output. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Tony Hosking wrote: > >> From: Tony Hosking >> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >> To: "Olaf Wagner" >> Cc: "Peter Eiserloh" , m3devel at elegosoft.com >> Date: Saturday, July 11, 2009, 8:19 AM >> I'd definitely need some way to reproduce the >> problem. Detailed instructions would be best. >> What platform are you running >> on? >> On 11 Jul 2009, at 06:47, Olaf >> Wagner >> wrote: >> Hm, I'm afraid we may have a regression >> in the runtime/gc here. >> CVSup always worked without problems for me (and still is >> copying >> FreeBSD, CM3 and other repositories between various >> machines for >> me and Elego). Surely CVSup is doing no such thing as >> keeping >> all its files in memory. >> >> I haven't tried the version Jay put into the CM3 repo >> though. >> So I see three possibilities: >> >> o Jay introduced the problem in the CVSup sources when he >> adapted them to the current CM3 (low >> probability). >> >> o You've got a broken runtime / CM3 version (and >> current >> sources work). I'd guess you are using the >> current version though. >> >> o We've got a problem in our runtime code, perhaps -- >> but not >> necessarily -- the garbage collector. >> >> I'd suggest we rule out the second one and you >> reproduce the problem >> with a current source set (if not done yet). Then let's >> see what Jay >> and Antony have to say, as they did almost all the source >> changes >> in that area recently. >> >> Olaf >> >> Quoting Peter Eiserloh : >> >> Hi Olaf, >> >> Well, I tried CVSup, >> and it started looking real good, until >> it crashed, with a >> message from the M3 runtime, saying that >> NEW could not allocate >> any memory. >> >> So I ran it a second >> time, and it got further, then crashed >> again. >> >> So, a third time, but >> with "top" running in another window, >> and sure enough cvsup, >> was allocating something like 1.2 GB >> of data before it was >> crashing. This is bigger than the >> CVS repository that it >> had already downloaded. >> >> I am thinking that >> cvsup is keeping the contents of every >> file it downloaded in >> memory. If so, this is a problem. >> >> If it is properly >> removing references, then maybe the >> garbage collector is >> failing. This would be a bigger >> problem, but with our >> compiler's runtime library. >> >> Are other people >> noticing problems. Is it just me? >> Am I the only one to >> attempt downloading the entire >> CVS repository for >> CM3? Could you try it? >> >> >> I sent an email to the >> email listed in cvsup's "about box" >> (cvsup-bugs at polstra.com), >> but that failed. The email address >> no longer works. >> >> peter at black:/data/modula-3/cm3 $ >> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >> cvsupfile.cm3 >> >> *** >> *** runtime error: >> *** >> NEW() was unable to allocate more memory. >> *** >> file >> "../src/runtime/common/RuntimeError.m3", line 63 >> *** >> >> Aborted >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh >> | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, >> Olaf Wagner >> wrote: >> >> From: Olaf Wagner >> Subject: Re: m3gdb and >> YACC >> To: "Peter >> Eiserloh" >> Date: Saturday, July 11, >> 2009, 2:49 AM >> Quoting Peter Eiserloh >> : >> >>> Hi Olaf, >>> >>> The import script >> (git-importcvs) internally uses >> cvsps, which >>> you may already >> have. >>> >>> Anyways, here is >> the first ten lines from a log file >> of an import >>> that I just >> started. >>> >>> >>> peter at black:~ $ >> head Import-cm3-20090708.log >>> Running cvsps... >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/etc/make-stds.texi on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/.brik on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >> unnamed branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >> unnamed >> branch >>> WARNING: revision >> 1.1.3.1 of file >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >> unnamed >> branch >> >> It looks like these >> files have a second vendor branch >> without a >> proper name. CVS does >> not cope well with multiple vendor >> branches >> (in fact it never really >> worked), but there won't be any >> valuable >> information in that >> branch I'm sure, so you can ignore it. >> >>> Later this weekend, >> I will attempt to use CVSup. >> First, >>> I will have to find >> usable documentation, since I >> have >>> never used CVSup >> before. >>> >>> Do you have a >> script to use with CVSup to access the >>> CM3 CVS repo? >> I am lasy. >>> >>> I use 'git' >> for all my current projects. I used >> to use >>> CVS, and had >> started looking into using subversion >> (SVN), >>> I even purchased a >> couple books on SVN. Then >> 'git' burst >>> upon the Linux >> world, and is gaining converts all over >> the >>> place. >>> >>> It really does >> provide a better work-flow. The >> easy >>> creation of a >> branch is a given, it is git's ability >>> to do easy merges, >> which is gaining all the good >> reputation. >>> >>> Rather than get all >> evangelistic on you, as I am sure >> you >>> have already heard >> it many times already. >>> >>> Many businesses are >> moving to git. The only >> problem some >>> enterprise >> companies are having is the ability to >> restrict >>> access of >> authorized users to only portions of the >> repository. >>> These types of >> problems don't effect open source >> software >>> development. >>> >>> Once I have a >> working 'git' repository for cm3, I will >> share >>> the technique, and >> maybe, start the foundations for a >>> transition from >> CVS, towards 'git'. But I >> suggest a slow >>> process, with >> distinct stages. At any >> stage we could stop, >>> or even revert. >>> >>> The problem is that >> once people start using git, they >> don''t >>> want to go back to >> using CVS, or any of the older >> methods. >>> Maybe that >> isn't so much of a problem after all. >>> >>> STAGE-1: Simple >> mirror of the CVS archive, >> periodically >>> >> updated (say once >> every 6 hours). >> Document on >>> >> web site, as to how >> to clone, and update a >> git >>> >> repository. No >> uploads to git. >>> STAGE-2: Convert >> web page scripts to use git. >>> STAGE-3: Convert >> tinderbox. >>> STAGE-4: Uploads to >> git. Install gitosis or >> similar server >>> >> for git uploads. >> Document the upload >> process on web >>> >> pages. >>> STAGE-5: CVS >> mirrors the git repo. Uploads to >> git only. >>> STAGE-6: Move last >> of the CVS people, over to git. >>> STAGE-7: Remove >> CVS. (optional) >> >> Let's see how far >> you get. Converting all the >> infrastructure (scripts >> and documentation) may >> be much more work than you imagine. >> And one >> we propose a special >> tool (be it git or svn or mercurial) >> there will >> start discussions on >> what is best and what we should do >> :-/ >> >> So offering an optional >> alternative access may be a good >> plan. >> The majority of users >> should agree that they want the >> change though. >> And we need to consider >> use of GUIs and Windows users, >> too. >> >> Olaf >> --Olaf Wagner -- elego >> Software Solutions GmbH >> >> >> Gustav-Meyer-Allee 25 / >> Geb?ude 12, 13355 >> Berlin, Germany >> phone: +49 30 23 45 86 >> 96 mobile: +49 177 2345 >> 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com >> | >> Gesch?ftsf?hrer: Olaf >> Wagner | Sitz: Berlin >> Handelregister: >> Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> >> >> >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> >> Gustav-Meyer-Allee >> 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 >> fax: +49 30 23 45 86 95 >> http://www.elegosoft.com >> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >> >> >> > > > From eiserlohpp at yahoo.com Sun Jul 12 20:26:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 12 Jul 2009 11:26:12 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <195840.65922.qm@web56808.mail.re3.yahoo.com> Hi Tony, Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz right now. In the mean time, I wish to report that CVSup on PPC_DARWIN built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, did run to completion. Top indicated that over 2 GB of virtual memory was being used, and over 700 MB of resident memory (ie, RAM). CVSup, used most of my CPU, making any other process (such as Finder) very difficult from which to work. Maybe we should "nice" it, or recommend is be run with "nice". Oh, well one thing at a time. BTW: The "about" box, found by clicking on the little "i" icon in the lower right corner is woefully out of date (eg. I had tried to report bugs to cvsup-bugs at polstra.org, but the email failed to get delivered). The copyright is also listed as 2003, six years ago. The reference to cvsup.org does work however. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 7/11/09, Tony Hosking wrote: > From: Tony Hosking > Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC > To: "Peter Eiserloh" > Cc: "Olaf Wagner" , m3devel at elegosoft.com > Date: Saturday, July 11, 2009, 2:31 PM > Please try my recent commits from > earlier to day. > > On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: > > > > > Hi Tony, > > > > Architecture: AMD64_LINUX. > > Code base: 20090628. > > > > I am untarring 20090710 right now, and will rebuild > the > > CM3 against it using the standard > scripts/do-cm3-std.sh > > > > I don't expect any difference in behavior though as > that > > is pretty much what my Makefile does anyways. > > > > Okay, I can also try this on my old Macintosh > (PPC_DARWIN). > > > > > > Are there any additional diagnostics that I can turn > on > > in the runtime?? Something simple may help like > when NEW > > complains, printing out: > >? o the size of memory currently allocated, > >? o the current number of allocations, > >? o the total number of allocations performed, > >? o the number of garbage collection runs > performed, and > >? o the number of objects reclaimed by the garbage > collector, > > and so forth. > > > > This may be difficult since we just failed to > allocate, > > memory, the diagnostics may not have the ability to > > format strings for output. > > > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? | > > > +--------------------------------------------------------+ > > > > > > --- On Sat, 7/11/09, Tony Hosking > wrote: > > > >> From: Tony Hosking > >> Subject: Re: [M3devel] CVSup crashing WAS: Re: > m3gdb and YACC > >> To: "Olaf Wagner" > >> Cc: "Peter Eiserloh" , > m3devel at elegosoft.com > >> Date: Saturday, July 11, 2009, 8:19 AM > >> I'd definitely need some way to reproduce the > >> problem.? Detailed instructions would be > best. > >>? What platform are you running > >> on? > >> On 11 Jul 2009, at 06:47, Olaf > >> Wagner > >> wrote: > >> Hm, I'm afraid we may have a regression > >> in the runtime/gc here. > >> CVSup always worked without problems for me (and > still is > >> copying > >> FreeBSD, CM3 and other repositories between > various > >> machines for > >> me and Elego). Surely CVSup is doing no such thing > as > >> keeping > >> all its files in memory. > >> > >> I haven't tried the version Jay put into the CM3 > repo > >> though. > >> So I see three possibilities: > >> > >> o Jay introduced the problem in the CVSup sources > when he > >>???adapted them to the current CM3 > (low > >> probability). > >> > >> o You've got a broken runtime / CM3 version (and > >> current > >>???sources work). I'd guess you are > using the > >> current version though. > >> > >> o We've got a problem in our runtime code, perhaps > -- > >> but not > >>???necessarily -- the garbage > collector. > >> > >> I'd suggest we rule out the second one and you > >> reproduce the problem > >> with a current source set (if not done yet). Then > let's > >> see what Jay > >> and Antony have to say, as they did almost all the > source > >> changes > >> in that area recently. > >> > >> Olaf > >> > >> Quoting Peter Eiserloh : > >> > >> Hi Olaf, > >> > >> Well, I tried CVSup, > >> and it started looking real good, until > >> it crashed, with a > >> message from the M3 runtime, saying that > >> NEW could not allocate > >> any memory. > >> > >> So I ran it a second > >> time, and it got further, then crashed > >> again. > >> > >> So, a third time, but > >> with "top" running in another window, > >> and sure enough cvsup, > >> was allocating something like 1.2 GB > >> of data before it was > >> crashing.? This is bigger than the > >> CVS repository that it > >> had already downloaded. > >> > >> I am thinking that > >> cvsup is keeping the contents of every > >> file it downloaded in > >> memory.? If so, this is a problem. > >> > >> If it is properly > >> removing references, then maybe the > >> garbage collector is > >> failing.? This would be a bigger > >> problem, but with our > >> compiler's runtime library. > >> > >> Are other people > >> noticing problems.? Is it just me? > >> Am I the only one to > >> attempt downloading the entire > >> CVS repository for > >> CM3?? Could you try it? > >> > >> > >> I sent an email to the > >> email listed in cvsup's "about box" > >> (cvsup-bugs at polstra.com), > >> but that failed.? The email address > >> no longer works. > >> > >> peter at black:/data/modula-3/cm3 $ > >>? > debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup > >> cvsupfile.cm3 > >> > >> *** > >> *** runtime error: > >> *** > >>? ? NEW() was unable to allocate more > memory. > >> *** > >>? ? file > >> "../src/runtime/common/RuntimeError.m3", line 63 > >> *** > >> > >> Aborted > >> > >> Peter > >> > >> > >> > +--------------------------------------------------------+ > >> | Peter P. Eiserloh > >>? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? | > >> > +--------------------------------------------------------+ > >> > >> > >> --- On Sat, 7/11/09, > >> Olaf Wagner > >> wrote: > >> > >> From: Olaf Wagner > >> Subject: Re: m3gdb and > >> YACC > >> To: "Peter > >> Eiserloh" > >> Date: Saturday, July 11, > >> 2009, 2:49 AM > >> Quoting Peter Eiserloh > >> : > >> > >>> Hi Olaf, > >>> > >>> The import script > >> (git-importcvs) internally uses > >> cvsps, which > >>> you may already > >> have. > >>> > >>> Anyways, here is > >> the first ten lines from a log file > >> of an import > >>> that I just > >> started. > >>> > >>> > >>> peter at black:~ $ > >> head Import-cm3-20090708.log > >>> Running cvsps... > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/etc/make-stds.texi? on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/.brik on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on > >> unnamed branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on > >> unnamed > >> branch > >>> WARNING: revision > >> 1.1.3.1 of file > >> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on > >> unnamed > >> branch > >> > >> It looks like these > >> files have a second vendor branch > >> without a > >> proper name. CVS does > >> not cope well with multiple vendor > >> branches > >> (in fact it never really > >> worked), but there won't be any > >> valuable > >> information in that > >> branch I'm sure, so you can ignore it. > >> > >>> Later this weekend, > >> I will attempt to use CVSup. > >> First, > >>> I will have to find > >> usable documentation, since I > >> have > >>> never used CVSup > >> before. > >>> > >>> Do you have a > >> script to use with CVSup to access the > >>> CM3 CVS repo? > >> I am lasy. > >>> > >>> I use 'git' > >> for all my current projects.? I used > >> to use > >>> CVS, and had > >> started looking into using subversion > >> (SVN), > >>> I even purchased a > >> couple books on SVN.? Then > >> 'git' burst > >>> upon the Linux > >> world, and is gaining converts all over > >> the > >>> place. > >>> > >>> It really does > >> provide a better work-flow.? The > >> easy > >>> creation of a > >> branch is a given, it is git's ability > >>> to do easy merges, > >> which is gaining all the good > >> reputation. > >>> > >>> Rather than get all > >> evangelistic on you, as I am sure > >> you > >>> have already heard > >> it many times already. > >>> > >>> Many businesses are > >> moving to git.? The only > >> problem some > >>> enterprise > >> companies are having is the ability to > >> restrict > >>> access of > >> authorized users to only portions of the > >> repository. > >>> These types of > >> problems don't effect open source > >> software > >>> development. > >>> > >>> Once I have a > >> working 'git' repository for cm3, I will > >> share > >>> the technique, and > >> maybe, start the foundations for a > >>> transition from > >> CVS, towards 'git'.? But I > >> suggest a slow > >>> process, with > >> distinct stages.???At any > >> stage we could stop, > >>> or even revert. > >>> > >>> The problem is that > >> once people start using git, they > >> don''t > >>> want to go back to > >> using CVS, or any of the older > >> methods. > >>> Maybe that > >> isn't so much of a problem after all. > >>> > >>> STAGE-1: Simple > >> mirror of the CVS archive, > >> periodically > >>> > >>? ???updated (say once > >> every 6 hours). > >> Document on > >>> > >>? ???web site, as to how > >> to clone, and update a > >> git > >>> > >>? ???repository.? No > >> uploads to git. > >>> STAGE-2: Convert > >> web page scripts to use git. > >>> STAGE-3: Convert > >> tinderbox. > >>> STAGE-4: Uploads to > >> git.? Install gitosis or > >> similar server > >>> > >>? ???for git uploads. > >> Document the upload > >> process on web > >>> > >>? ???pages. > >>> STAGE-5: CVS > >> mirrors the git repo.? Uploads to > >> git only. > >>> STAGE-6: Move last > >> of the CVS people, over to git. > >>> STAGE-7: Remove > >> CVS.? (optional) > >> > >> Let's see how far > >> you get. Converting all the > >> infrastructure (scripts > >> and documentation) may > >> be much more work than you imagine. > >> And one > >> we propose a special > >> tool (be it git or svn or mercurial) > >> there will > >> start discussions on > >> what is best and what we should do > >> :-/ > >> > >> So offering an optional > >> alternative access may be a good > >> plan. > >> The majority of users > >> should agree that they want the > >> change though. > >> And we need to consider > >> use of GUIs and Windows users, > >> too. > >> > >> Olaf > >> --Olaf Wagner -- elego > >> Software Solutions GmbH > >> > >> > >>? ? Gustav-Meyer-Allee 25 / > >> Geb?ude 12, 13355 > >> Berlin, Germany > >> phone: +49 30 23 45 86 > >> 96? mobile: +49 177 2345 > >> 869? fax: +49 30 23 > >> 45 86 95 > >>? ? http://www.elegosoft.com > >> | > >> Gesch?ftsf?hrer: Olaf > >> Wagner | Sitz: Berlin > >> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | > >> USt-IdNr: DE163214194 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Olaf Wagner -- elego Software Solutions GmbH > >> > >>? ? ? ? ? ? > ???Gustav-Meyer-Allee > >> 25 / Geb?ude 12, 13355 Berlin, Germany > >> phone: +49 30 23 45 86 96? mobile: +49 177 > 2345 869 > >>? fax: +49 30 23 45 86 95 > >>???http://www.elegosoft.com > >> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > >> Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > >> USt-IdNr: DE163214194 > >> > >> > >> > > > > > > > > From hosking at cs.purdue.edu Sun Jul 12 21:17:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Jul 2009 15:17:34 -0400 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: <195840.65922.qm@web56808.mail.re3.yahoo.com> References: <195840.65922.qm@web56808.mail.re3.yahoo.com> Message-ID: You should find the footprint much smaller now. I'm interested to find out what it turns out to be. On 12 Jul 2009, at 14:26, Peter Eiserloh wrote: > > Hi Tony, > > Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz > right now. > > In the mean time, I wish to report that CVSup on PPC_DARWIN > built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, > did run to completion. Top indicated that over 2 GB of > virtual memory was being used, and over 700 MB of resident > memory (ie, RAM). > > CVSup, used most of my CPU, making any other process (such > as Finder) very difficult from which to work. Maybe we should > "nice" it, or recommend is be run with "nice". Oh, well > one thing at a time. > > BTW: The "about" box, found by clicking on the little "i" icon > in the lower right corner is woefully out of date (eg. I had > tried to report bugs to cvsup-bugs at polstra.org, but the email > failed to get delivered). The copyright is also listed as 2003, > six years ago. > > The reference to cvsup.org does work however. > > > Peter > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 7/11/09, Tony Hosking wrote: > >> From: Tony Hosking >> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >> To: "Peter Eiserloh" >> Cc: "Olaf Wagner" , m3devel at elegosoft.com >> Date: Saturday, July 11, 2009, 2:31 PM >> Please try my recent commits from >> earlier to day. >> >> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: >> >>> >>> Hi Tony, >>> >>> Architecture: AMD64_LINUX. >>> Code base: 20090628. >>> >>> I am untarring 20090710 right now, and will rebuild >> the >>> CM3 against it using the standard >> scripts/do-cm3-std.sh >>> >>> I don't expect any difference in behavior though as >> that >>> is pretty much what my Makefile does anyways. >>> >>> Okay, I can also try this on my old Macintosh >> (PPC_DARWIN). >>> >>> >>> Are there any additional diagnostics that I can turn >> on >>> in the runtime? Something simple may help like >> when NEW >>> complains, printing out: >>> o the size of memory currently allocated, >>> o the current number of allocations, >>> o the total number of allocations performed, >>> o the number of garbage collection runs >> performed, and >>> o the number of objects reclaimed by the garbage >> collector, >>> and so forth. >>> >>> This may be difficult since we just failed to >> allocate, >>> memory, the diagnostics may not have the ability to >>> format strings for output. >>> >>> >>> >> +--------------------------------------------------------+ >>> | Peter P. Eiserloh >> >> | >>> >> +--------------------------------------------------------+ >>> >>> >>> --- On Sat, 7/11/09, Tony Hosking >> wrote: >>> >>>> From: Tony Hosking >>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: >> m3gdb and YACC >>>> To: "Olaf Wagner" >>>> Cc: "Peter Eiserloh" , >> m3devel at elegosoft.com >>>> Date: Saturday, July 11, 2009, 8:19 AM >>>> I'd definitely need some way to reproduce the >>>> problem. Detailed instructions would be >> best. >>>> What platform are you running >>>> on? >>>> On 11 Jul 2009, at 06:47, Olaf >>>> Wagner >>>> wrote: >>>> Hm, I'm afraid we may have a regression >>>> in the runtime/gc here. >>>> CVSup always worked without problems for me (and >> still is >>>> copying >>>> FreeBSD, CM3 and other repositories between >> various >>>> machines for >>>> me and Elego). Surely CVSup is doing no such thing >> as >>>> keeping >>>> all its files in memory. >>>> >>>> I haven't tried the version Jay put into the CM3 >> repo >>>> though. >>>> So I see three possibilities: >>>> >>>> o Jay introduced the problem in the CVSup sources >> when he >>>> adapted them to the current CM3 >> (low >>>> probability). >>>> >>>> o You've got a broken runtime / CM3 version (and >>>> current >>>> sources work). I'd guess you are >> using the >>>> current version though. >>>> >>>> o We've got a problem in our runtime code, perhaps >> -- >>>> but not >>>> necessarily -- the garbage >> collector. >>>> >>>> I'd suggest we rule out the second one and you >>>> reproduce the problem >>>> with a current source set (if not done yet). Then >> let's >>>> see what Jay >>>> and Antony have to say, as they did almost all the >> source >>>> changes >>>> in that area recently. >>>> >>>> Olaf >>>> >>>> Quoting Peter Eiserloh : >>>> >>>> Hi Olaf, >>>> >>>> Well, I tried CVSup, >>>> and it started looking real good, until >>>> it crashed, with a >>>> message from the M3 runtime, saying that >>>> NEW could not allocate >>>> any memory. >>>> >>>> So I ran it a second >>>> time, and it got further, then crashed >>>> again. >>>> >>>> So, a third time, but >>>> with "top" running in another window, >>>> and sure enough cvsup, >>>> was allocating something like 1.2 GB >>>> of data before it was >>>> crashing. This is bigger than the >>>> CVS repository that it >>>> had already downloaded. >>>> >>>> I am thinking that >>>> cvsup is keeping the contents of every >>>> file it downloaded in >>>> memory. If so, this is a problem. >>>> >>>> If it is properly >>>> removing references, then maybe the >>>> garbage collector is >>>> failing. This would be a bigger >>>> problem, but with our >>>> compiler's runtime library. >>>> >>>> Are other people >>>> noticing problems. Is it just me? >>>> Am I the only one to >>>> attempt downloading the entire >>>> CVS repository for >>>> CM3? Could you try it? >>>> >>>> >>>> I sent an email to the >>>> email listed in cvsup's "about box" >>>> (cvsup-bugs at polstra.com), >>>> but that failed. The email address >>>> no longer works. >>>> >>>> peter at black:/data/modula-3/cm3 $ >>>> >> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >>>> cvsupfile.cm3 >>>> >>>> *** >>>> *** runtime error: >>>> *** >>>> NEW() was unable to allocate more >> memory. >>>> *** >>>> file >>>> "../src/runtime/common/RuntimeError.m3", line 63 >>>> *** >>>> >>>> Aborted >>>> >>>> Peter >>>> >>>> >>>> >> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh >>>> >> >> | >>>> >> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, >>>> Olaf Wagner >>>> wrote: >>>> >>>> From: Olaf Wagner >>>> Subject: Re: m3gdb and >>>> YACC >>>> To: "Peter >>>> Eiserloh" >>>> Date: Saturday, July 11, >>>> 2009, 2:49 AM >>>> Quoting Peter Eiserloh >>>> : >>>> >>>>> Hi Olaf, >>>>> >>>>> The import script >>>> (git-importcvs) internally uses >>>> cvsps, which >>>>> you may already >>>> have. >>>>> >>>>> Anyways, here is >>>> the first ten lines from a log file >>>> of an import >>>>> that I just >>>> started. >>>>> >>>>> >>>>> peter at black:~ $ >>>> head Import-cm3-20090708.log >>>>> Running cvsps... >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/etc/make-stds.texi on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/.brik on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >>>> unnamed branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >>>> unnamed >>>> branch >>>>> WARNING: revision >>>> 1.1.3.1 of file >>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >>>> unnamed >>>> branch >>>> >>>> It looks like these >>>> files have a second vendor branch >>>> without a >>>> proper name. CVS does >>>> not cope well with multiple vendor >>>> branches >>>> (in fact it never really >>>> worked), but there won't be any >>>> valuable >>>> information in that >>>> branch I'm sure, so you can ignore it. >>>> >>>>> Later this weekend, >>>> I will attempt to use CVSup. >>>> First, >>>>> I will have to find >>>> usable documentation, since I >>>> have >>>>> never used CVSup >>>> before. >>>>> >>>>> Do you have a >>>> script to use with CVSup to access the >>>>> CM3 CVS repo? >>>> I am lasy. >>>>> >>>>> I use 'git' >>>> for all my current projects. I used >>>> to use >>>>> CVS, and had >>>> started looking into using subversion >>>> (SVN), >>>>> I even purchased a >>>> couple books on SVN. Then >>>> 'git' burst >>>>> upon the Linux >>>> world, and is gaining converts all over >>>> the >>>>> place. >>>>> >>>>> It really does >>>> provide a better work-flow. The >>>> easy >>>>> creation of a >>>> branch is a given, it is git's ability >>>>> to do easy merges, >>>> which is gaining all the good >>>> reputation. >>>>> >>>>> Rather than get all >>>> evangelistic on you, as I am sure >>>> you >>>>> have already heard >>>> it many times already. >>>>> >>>>> Many businesses are >>>> moving to git. The only >>>> problem some >>>>> enterprise >>>> companies are having is the ability to >>>> restrict >>>>> access of >>>> authorized users to only portions of the >>>> repository. >>>>> These types of >>>> problems don't effect open source >>>> software >>>>> development. >>>>> >>>>> Once I have a >>>> working 'git' repository for cm3, I will >>>> share >>>>> the technique, and >>>> maybe, start the foundations for a >>>>> transition from >>>> CVS, towards 'git'. But I >>>> suggest a slow >>>>> process, with >>>> distinct stages. At any >>>> stage we could stop, >>>>> or even revert. >>>>> >>>>> The problem is that >>>> once people start using git, they >>>> don''t >>>>> want to go back to >>>> using CVS, or any of the older >>>> methods. >>>>> Maybe that >>>> isn't so much of a problem after all. >>>>> >>>>> STAGE-1: Simple >>>> mirror of the CVS archive, >>>> periodically >>>>> >>>> updated (say once >>>> every 6 hours). >>>> Document on >>>>> >>>> web site, as to how >>>> to clone, and update a >>>> git >>>>> >>>> repository. No >>>> uploads to git. >>>>> STAGE-2: Convert >>>> web page scripts to use git. >>>>> STAGE-3: Convert >>>> tinderbox. >>>>> STAGE-4: Uploads to >>>> git. Install gitosis or >>>> similar server >>>>> >>>> for git uploads. >>>> Document the upload >>>> process on web >>>>> >>>> pages. >>>>> STAGE-5: CVS >>>> mirrors the git repo. Uploads to >>>> git only. >>>>> STAGE-6: Move last >>>> of the CVS people, over to git. >>>>> STAGE-7: Remove >>>> CVS. (optional) >>>> >>>> Let's see how far >>>> you get. Converting all the >>>> infrastructure (scripts >>>> and documentation) may >>>> be much more work than you imagine. >>>> And one >>>> we propose a special >>>> tool (be it git or svn or mercurial) >>>> there will >>>> start discussions on >>>> what is best and what we should do >>>> :-/ >>>> >>>> So offering an optional >>>> alternative access may be a good >>>> plan. >>>> The majority of users >>>> should agree that they want the >>>> change though. >>>> And we need to consider >>>> use of GUIs and Windows users, >>>> too. >>>> >>>> Olaf >>>> --Olaf Wagner -- elego >>>> Software Solutions GmbH >>>> >>>> >>>> Gustav-Meyer-Allee 25 / >>>> Geb?ude 12, 13355 >>>> Berlin, Germany >>>> phone: +49 30 23 45 86 >>>> 96 mobile: +49 177 2345 >>>> 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com >>>> | >>>> Gesch?ftsf?hrer: Olaf >>>> Wagner | Sitz: Berlin >>>> Handelregister: >>>> Amtsgericht Charlottenburg HRB 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> >>>> >> Gustav-Meyer-Allee >>>> 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 869 >>>> fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com >>>> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | >>>> USt-IdNr: DE163214194 >>>> >>>> >>>> >>> >>> >>> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 13 04:55:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Jul 2009 02:55:14 +0000 Subject: [M3devel] dynamic linking broken Message-ID: It looks like I might have broken dynamic linking, when I moved .so/.dylib files only to lib and not in pkg. At least on AMD64_DARWIN we get link commands like -L /cm3/pkg/m3core -lm3core but that directory only has libm3core.a. I'll investigate further and fix. Two likely fixes: 1 Change cm3 to point -L always just at /cm3/lib instead of /cm3/pkg. 2 symlink pkg out to lib - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 13 08:53:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 12 Jul 2009 23:53:28 -0700 Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC In-Reply-To: References: <195840.65922.qm@web56808.mail.re3.yahoo.com> Message-ID: <14943A9D-777A-45BE-A993-0289C24209CC@hotmail.com> Am I off the hook? Mika you often test user mode threads right? :) Starting with gc off isn't obviously definitely wrong, could be it gets enabled once initialization is further along. Or not. - Jay (phone) On Jul 12, 2009, at 12:17 PM, Tony Hosking wrote: > You should find the footprint much smaller now. I'm interested to > find out what it turns out to be. > > On 12 Jul 2009, at 14:26, Peter Eiserloh wrote: > >> >> Hi Tony, >> >> Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz >> right now. >> >> In the mean time, I wish to report that CVSup on PPC_DARWIN >> built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz, >> did run to completion. Top indicated that over 2 GB of >> virtual memory was being used, and over 700 MB of resident >> memory (ie, RAM). >> >> CVSup, used most of my CPU, making any other process (such >> as Finder) very difficult from which to work. Maybe we should >> "nice" it, or recommend is be run with "nice". Oh, well >> one thing at a time. >> >> BTW: The "about" box, found by clicking on the little "i" icon >> in the lower right corner is woefully out of date (eg. I had >> tried to report bugs to cvsup-bugs at polstra.org, but the email >> failed to get delivered). The copyright is also listed as 2003, >> six years ago. >> >> The reference to cvsup.org does work however. >> >> >> Peter >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 7/11/09, Tony Hosking wrote: >> >>> From: Tony Hosking >>> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC >>> To: "Peter Eiserloh" >>> Cc: "Olaf Wagner" , m3devel at elegosoft.com >>> Date: Saturday, July 11, 2009, 2:31 PM >>> Please try my recent commits from >>> earlier to day. >>> >>> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote: >>> >>>> >>>> Hi Tony, >>>> >>>> Architecture: AMD64_LINUX. >>>> Code base: 20090628. >>>> >>>> I am untarring 20090710 right now, and will rebuild >>> the >>>> CM3 against it using the standard >>> scripts/do-cm3-std.sh >>>> >>>> I don't expect any difference in behavior though as >>> that >>>> is pretty much what my Makefile does anyways. >>>> >>>> Okay, I can also try this on my old Macintosh >>> (PPC_DARWIN). >>>> >>>> >>>> Are there any additional diagnostics that I can turn >>> on >>>> in the runtime? Something simple may help like >>> when NEW >>>> complains, printing out: >>>> o the size of memory currently allocated, >>>> o the current number of allocations, >>>> o the total number of allocations performed, >>>> o the number of garbage collection runs >>> performed, and >>>> o the number of objects reclaimed by the garbage >>> collector, >>>> and so forth. >>>> >>>> This may be difficult since we just failed to >>> allocate, >>>> memory, the diagnostics may not have the ability to >>>> format strings for output. >>>> >>>> >>>> >>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh >>> >>> | >>>> >>> +--------------------------------------------------------+ >>>> >>>> >>>> --- On Sat, 7/11/09, Tony Hosking >>> wrote: >>>> >>>>> From: Tony Hosking >>>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: >>> m3gdb and YACC >>>>> To: "Olaf Wagner" >>>>> Cc: "Peter Eiserloh" , >>> m3devel at elegosoft.com >>>>> Date: Saturday, July 11, 2009, 8:19 AM >>>>> I'd definitely need some way to reproduce the >>>>> problem. Detailed instructions would be >>> best. >>>>> What platform are you running >>>>> on? >>>>> On 11 Jul 2009, at 06:47, Olaf >>>>> Wagner >>>>> wrote: >>>>> Hm, I'm afraid we may have a regression >>>>> in the runtime/gc here. >>>>> CVSup always worked without problems for me (and >>> still is >>>>> copying >>>>> FreeBSD, CM3 and other repositories between >>> various >>>>> machines for >>>>> me and Elego). Surely CVSup is doing no such thing >>> as >>>>> keeping >>>>> all its files in memory. >>>>> >>>>> I haven't tried the version Jay put into the CM3 >>> repo >>>>> though. >>>>> So I see three possibilities: >>>>> >>>>> o Jay introduced the problem in the CVSup sources >>> when he >>>>> adapted them to the current CM3 >>> (low >>>>> probability). >>>>> >>>>> o You've got a broken runtime / CM3 version (and >>>>> current >>>>> sources work). I'd guess you are >>> using the >>>>> current version though. >>>>> >>>>> o We've got a problem in our runtime code, perhaps >>> -- >>>>> but not >>>>> necessarily -- the garbage >>> collector. >>>>> >>>>> I'd suggest we rule out the second one and you >>>>> reproduce the problem >>>>> with a current source set (if not done yet). Then >>> let's >>>>> see what Jay >>>>> and Antony have to say, as they did almost all the >>> source >>>>> changes >>>>> in that area recently. >>>>> >>>>> Olaf >>>>> >>>>> Quoting Peter Eiserloh : >>>>> >>>>> Hi Olaf, >>>>> >>>>> Well, I tried CVSup, >>>>> and it started looking real good, until >>>>> it crashed, with a >>>>> message from the M3 runtime, saying that >>>>> NEW could not allocate >>>>> any memory. >>>>> >>>>> So I ran it a second >>>>> time, and it got further, then crashed >>>>> again. >>>>> >>>>> So, a third time, but >>>>> with "top" running in another window, >>>>> and sure enough cvsup, >>>>> was allocating something like 1.2 GB >>>>> of data before it was >>>>> crashing. This is bigger than the >>>>> CVS repository that it >>>>> had already downloaded. >>>>> >>>>> I am thinking that >>>>> cvsup is keeping the contents of every >>>>> file it downloaded in >>>>> memory. If so, this is a problem. >>>>> >>>>> If it is properly >>>>> removing references, then maybe the >>>>> garbage collector is >>>>> failing. This would be a bigger >>>>> problem, but with our >>>>> compiler's runtime library. >>>>> >>>>> Are other people >>>>> noticing problems. Is it just me? >>>>> Am I the only one to >>>>> attempt downloading the entire >>>>> CVS repository for >>>>> CM3? Could you try it? >>>>> >>>>> >>>>> I sent an email to the >>>>> email listed in cvsup's "about box" >>>>> (cvsup-bugs at polstra.com), >>>>> but that failed. The email address >>>>> no longer works. >>>>> >>>>> peter at black:/data/modula-3/cm3 $ >>>>> >>> debian-pkg/current/debian/tmp/usr/lib/cm3/bin/cvsup >>>>> cvsupfile.cm3 >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** >>>>> NEW() was unable to allocate more >>> memory. >>>>> *** >>>>> file >>>>> "../src/runtime/common/RuntimeError.m3", line 63 >>>>> *** >>>>> >>>>> Aborted >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>> +--------------------------------------------------------+ >>>>> | Peter P. Eiserloh >>>>> >>> >>> | >>>>> >>> +--------------------------------------------------------+ >>>>> >>>>> >>>>> --- On Sat, 7/11/09, >>>>> Olaf Wagner >>>>> wrote: >>>>> >>>>> From: Olaf Wagner >>>>> Subject: Re: m3gdb and >>>>> YACC >>>>> To: "Peter >>>>> Eiserloh" >>>>> Date: Saturday, July 11, >>>>> 2009, 2:49 AM >>>>> Quoting Peter Eiserloh >>>>> : >>>>> >>>>>> Hi Olaf, >>>>>> >>>>>> The import script >>>>> (git-importcvs) internally uses >>>>> cvsps, which >>>>>> you may already >>>>> have. >>>>>> >>>>>> Anyways, here is >>>>> the first ten lines from a log file >>>>> of an import >>>>>> that I just >>>>> started. >>>>>> >>>>>> >>>>>> peter at black:~ $ >>>>> head Import-cm3-20090708.log >>>>>> Running cvsps... >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/.brik on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on >>>>> unnamed branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on >>>>> unnamed >>>>> branch >>>>>> WARNING: revision >>>>> 1.1.3.1 of file >>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on >>>>> unnamed >>>>> branch >>>>> >>>>> It looks like these >>>>> files have a second vendor branch >>>>> without a >>>>> proper name. CVS does >>>>> not cope well with multiple vendor >>>>> branches >>>>> (in fact it never really >>>>> worked), but there won't be any >>>>> valuable >>>>> information in that >>>>> branch I'm sure, so you can ignore it. >>>>> >>>>>> Later this weekend, >>>>> I will attempt to use CVSup. >>>>> First, >>>>>> I will have to find >>>>> usable documentation, since I >>>>> have >>>>>> never used CVSup >>>>> before. >>>>>> >>>>>> Do you have a >>>>> script to use with CVSup to access the >>>>>> CM3 CVS repo? >>>>> I am lasy. >>>>>> >>>>>> I use 'git' >>>>> for all my current projects. I used >>>>> to use >>>>>> CVS, and had >>>>> started looking into using subversion >>>>> (SVN), >>>>>> I even purchased a >>>>> couple books on SVN. Then >>>>> 'git' burst >>>>>> upon the Linux >>>>> world, and is gaining converts all over >>>>> the >>>>>> place. >>>>>> >>>>>> It really does >>>>> provide a better work-flow. The >>>>> easy >>>>>> creation of a >>>>> branch is a given, it is git's ability >>>>>> to do easy merges, >>>>> which is gaining all the good >>>>> reputation. >>>>>> >>>>>> Rather than get all >>>>> evangelistic on you, as I am sure >>>>> you >>>>>> have already heard >>>>> it many times already. >>>>>> >>>>>> Many businesses are >>>>> moving to git. The only >>>>> problem some >>>>>> enterprise >>>>> companies are having is the ability to >>>>> restrict >>>>>> access of >>>>> authorized users to only portions of the >>>>> repository. >>>>>> These types of >>>>> problems don't effect open source >>>>> software >>>>>> development. >>>>>> >>>>>> Once I have a >>>>> working 'git' repository for cm3, I will >>>>> share >>>>>> the technique, and >>>>> maybe, start the foundations for a >>>>>> transition from >>>>> CVS, towards 'git'. But I >>>>> suggest a slow >>>>>> process, with >>>>> distinct stages. At any >>>>> stage we could stop, >>>>>> or even revert. >>>>>> >>>>>> The problem is that >>>>> once people start using git, they >>>>> don''t >>>>>> want to go back to >>>>> using CVS, or any of the older >>>>> methods. >>>>>> Maybe that >>>>> isn't so much of a problem after all. >>>>>> >>>>>> STAGE-1: Simple >>>>> mirror of the CVS archive, >>>>> periodically >>>>>> >>>>> updated (say once >>>>> every 6 hours). >>>>> Document on >>>>>> >>>>> web site, as to how >>>>> to clone, and update a >>>>> git >>>>>> >>>>> repository. No >>>>> uploads to git. >>>>>> STAGE-2: Convert >>>>> web page scripts to use git. >>>>>> STAGE-3: Convert >>>>> tinderbox. >>>>>> STAGE-4: Uploads to >>>>> git. Install gitosis or >>>>> similar server >>>>>> >>>>> for git uploads. >>>>> Document the upload >>>>> process on web >>>>>> >>>>> pages. >>>>>> STAGE-5: CVS >>>>> mirrors the git repo. Uploads to >>>>> git only. >>>>>> STAGE-6: Move last >>>>> of the CVS people, over to git. >>>>>> STAGE-7: Remove >>>>> CVS. (optional) >>>>> >>>>> Let's see how far >>>>> you get. Converting all the >>>>> infrastructure (scripts >>>>> and documentation) may >>>>> be much more work than you imagine. >>>>> And one >>>>> we propose a special >>>>> tool (be it git or svn or mercurial) >>>>> there will >>>>> start discussions on >>>>> what is best and what we should do >>>>> :-/ >>>>> >>>>> So offering an optional >>>>> alternative access may be a good >>>>> plan. >>>>> The majority of users >>>>> should agree that they want the >>>>> change though. >>>>> And we need to consider >>>>> use of GUIs and Windows users, >>>>> too. >>>>> >>>>> Olaf >>>>> --Olaf Wagner -- elego >>>>> Software Solutions GmbH >>>>> >>>>> >>>>> Gustav-Meyer-Allee 25 / >>>>> Geb?ude 12, 13355 >>>>> Berlin, Germany >>>>> phone: +49 30 23 45 86 >>>>> 96 mobile: +49 177 2345 >>>>> 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com >>>>> | >>>>> Gesch?ftsf?hrer: Olaf >>>>> Wagner | Sitz: Berlin >>>>> Handelregister: >>>>> Amtsgericht Charlottenburg HRB 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> >>>>> >>> Gustav-Meyer-Allee >>>>> 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 >>> 2345 869 >>>>> fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com >>>>> | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB >>> 77719 | >>>>> USt-IdNr: DE163214194 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 13 08:55:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Jul 2009 08:55:57 +0200 Subject: [M3devel] Fwd: Problems with the linker Message-ID: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> Something for Jay or Randy again... please help to find the correct linker. Olaf ----- Forwarded message from clever92000 at yahoo.com.br ----- Date: Sun, 12 Jul 2009 18:51:48 -0300 From: Cleverson Reply-To: Cleverson Subject: Problems with the linker To: m3-support at elego.de Hello: In case my following question can better be answered at the m3devel mailing list, please subscribe me. I'd like to learn Modula-3, so I'm trying to set up CM3 on my Windows XP system. I'm not sure about the differences between the "bin" and the "std" cm3 distributions, but from what I could understand, the later contains more pre-compiled DLL libraries, so I decided to go with it. I unpacked the file "cm3-std-NT386-d5.8.1.zip" to the root of my E: partition, then renamed the root cm3's folder to cm3, then set the PATH variable to include E:\cm3\bin. When I try to build a hello test program, I receive an error saying it cannot find the "link" command, then the linking process fails. The installation instructions state that I should have the Windows SDK. If my problem is actually that I'm missing it, can you point me to where I can grabe it please? Anyways, I'd like to know why cm3 doesn't have its own linker, that it needs the Windows SDK linker, unlike other language's compilers such as FreePascal? Many thanks for any help Cleverson ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 13 09:17:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Jul 2009 07:17:56 +0000 Subject: [M3devel] Fwd: Problems with the linker In-Reply-To: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> References: <20090713085557.ud7c42y9j44ccwsc@mail.elegosoft.com> Message-ID: Please buy or download one of the many Visual C++ versions, or one of the Windows SDKs that include a linker. Once installed, they should put a link on the start menu that launches a cmd/console/command line with %PATH% set to include link.exe. I'll make this a little easier maybe, but you still need a Microsoft linker. Options include but are not limited to: http://www.microsoft.com/express/vc/ This might nag you to register but I think to just use the command line you don't have to. http://www.microsoft.com/downloads/details.aspx?familyid=E6E1C3DF-A74F-4207-8586-711EBE331CDC (see how it says "including compilers") some of these: http://mssdk.orderport.net/22221848/showall.asp - Jay > Date: Mon, 13 Jul 2009 08:55:57 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Problems with the linker > > Something for Jay or Randy again... please help to find the correct linker. > > Olaf > > ----- Forwarded message from clever92000 at yahoo.com.br ----- > Date: Sun, 12 Jul 2009 18:51:48 -0300 > From: Cleverson > Reply-To: Cleverson > Subject: Problems with the linker > To: m3-support at elego.de > > Hello: > > In case my following question can better be answered at the m3devel > mailing list, please subscribe me. > > I'd like to learn Modula-3, so I'm trying to set up CM3 on my Windows XP > system. I'm not sure about the differences between the "bin" and the > "std" cm3 distributions, but from what I could understand, the later > contains more pre-compiled DLL libraries, so I decided to go with it. > > I unpacked the file "cm3-std-NT386-d5.8.1.zip" to the root of my E: > partition, then renamed the root cm3's folder to cm3, then set the PATH > variable to include E:\cm3\bin. When I try to build a hello test > program, I receive an error saying it cannot find the "link" command, > then the linking process fails. > > The installation instructions state that I should have the Windows SDK. > If my problem is actually that I'm missing it, can you point me to where > I can grabe it please? > > Anyways, I'd like to know why cm3 doesn't have its own linker, that it > needs the Windows SDK linker, unlike other language's compilers such as > FreePascal? > > Many thanks for any help > > Cleverson > > > ----- End forwarded message ----- > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Mon Jul 13 12:24:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 13 Jul 2009 03:24:58 -0700 (PDT) Subject: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC Message-ID: <274088.73864.qm@web56804.mail.re3.yahoo.com> Hi Tony, You recent commit, sure looks like it did the trick. CVSup has gotten to the point where it used to crash, and much further. Where before it used to take up over 75% of my memory, now it is at 1.6% (yes, less than 2%). It has also been working for over 14 minutes, and still going strong. Before it wouldn't last for more than 3 minutes. Thank you very much. Another regression bites the dust! +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > >>> From: Tony Hosking > >>> Subject: Re: [M3devel] CVSup crashing WAS: Re: > m3gdb and YACC > >>> To: "Peter Eiserloh" > >>> Cc: "Olaf Wagner" , > m3devel at elegosoft.com > >>> Date: Saturday, July 11, 2009, 2:31 PM > >>> Please try my recent commits from > >>> earlier to day. > >>> From jay.krell at cornell.edu Tue Jul 14 02:10:30 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 13 Jul 2009 17:10:30 -0700 Subject: [M3devel] dynamic linking broken In-Reply-To: References: Message-ID: <28CA8259-DA9C-4A4F-AA1B-1F01CFE3DE2B@hotmail.com> It should be ok now though I didn't test the solaris part. Hopefully a better construct soon like 'InstallSymbolicLink' without the limitations of the current functions, to reduce the indirection. - Jay (phone) On Jul 12, 2009, at 7:55 PM, Jay K wrote: > It looks like I might have broken dynamic linking, when I > moved .so/.dylib files only to lib and not in pkg. > > At least on AMD64_DARWIN we get link commands like > > -L /cm3/pkg/m3core -lm3core > > but that directory only has libm3core.a. > > I'll investigate further and fix. > > Two likely fixes: > 1 Change cm3 to point -L always just at /cm3/lib instead of /cm3/pkg. > 2 symlink pkg out to lib > > - Jay > > > > From wagner at elegosoft.com Wed Jul 15 08:31:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 08:31:40 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze Message-ID: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Hi all, I'm currently tagging the source base with release_CM3_5_8_RC2. The reported compiler vesion will be d5.8.2 for this RC. There seems to be a neverending stream of commits, which makes it quite difficult to choose a good time to do this, but I hope that Tinderbox will show no major problems with the tagged sources. I'd like everybody for the next weeks to postpone their functional changes and concentrate on testing and fixing bugs that are found or already known. If anybody knows of any problems with the current tag we can still move it in places _before_ we build any release archives. Tagging the whole repository is a quite costly operation in CVS. To summarize: o refrain from functional changes o report and correct bugs o don't build any distribution archives until we've agreed we've tagged a good source set I'll perform some testing myself and try to prepare a draft for the release notes (a lot of changes occured in the recent years) within the next days. Thanks for your patience and your contribution, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 09:27:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 07:27:44 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: How does one checkout, update or commit to RC2 and beyond RC2? There is still maybe the formsedit crash. I'll verify soon. Ideally we get to a situation in which distributions are built every day and what we ship is merely picked among them. I need to ever get Tinderbox working and under cron or in a loop. I also wonder if we should go back to 5.7.something, since we burned through 5.7 fairly fast. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 08:31:40 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: m3-support at elego.de > Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > There seems to be a neverending stream of commits, which makes > it quite difficult to choose a good time to do this, but I hope > that Tinderbox will show no major problems with the tagged sources. > > I'd like everybody for the next weeks to postpone their functional > changes and concentrate on testing and fixing bugs that are found > or already known. If anybody knows of any problems with the current > tag we can still move it in places _before_ we build any release > archives. Tagging the whole repository is a quite costly operation > in CVS. > > To summarize: > > o refrain from functional changes > o report and correct bugs > o don't build any distribution archives until we've agreed we've > tagged a good source set > > I'll perform some testing myself and try to prepare a draft for the > release notes (a lot of changes occured in the recent years) within the > next days. > > Thanks for your patience and your contribution, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 15 11:33:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 11:33:56 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Quoting Jay K : > How does one checkout, update or commit to RC2 and beyond RC2? No changes here. I'd just like to avoid branching for the release, and concentrate work on it. > There is still maybe the formsedit crash. I'll verify soon. > > Ideally we get to a situation in which distributions are built every > day and what we ship is merely picked among them. I need to ever > get Tinderbox working and under cron or in a loop. > > I also wonder if we should go back to 5.7.something, since we burned > through 5.7 fairly fast. Please, let's just provide one stable official release, and not confuse anybody by using old version numbers. Olaf > ---------------------------------------- >> Date: Wed, 15 Jul 2009 08:31:40 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> CC: m3-support at elego.de >> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> There seems to be a neverending stream of commits, which makes >> it quite difficult to choose a good time to do this, but I hope >> that Tinderbox will show no major problems with the tagged sources. >> >> I'd like everybody for the next weeks to postpone their functional >> changes and concentrate on testing and fixing bugs that are found >> or already known. If anybody knows of any problems with the current >> tag we can still move it in places _before_ we build any release >> archives. Tagging the whole repository is a quite costly operation >> in CVS. >> >> To summarize: >> >> o refrain from functional changes >> o report and correct bugs >> o don't build any distribution archives until we've agreed we've >> tagged a good source set >> >> I'll perform some testing myself and try to prepare a draft for the >> release notes (a lot of changes occured in the recent years) within the >> next days. >> >> Thanks for your patience and your contribution, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 13:41:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 11:41:38 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715113356.30raw28b74og08kk@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: I'd still like to: reduce the indirection in the recently introduced symlinks..it is a small change (that's what I always say!) (though the movement from pkg to lib I wouldn't call small) improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others These might be be mostly just: - updating RTSignalC.c - updating the GNU configuration name for AMD64_SOLARIS in m3cc/src/m3makefile - fix my Python scripts to consume the master package list, build m3gdb, build cm3ide, build in dependency order (huh, I thought they always did, now not sure), add your feature of passing on extra parameteres to cm3 - maybe change the *.sh files to accept parameters in any order like the *.py - maybe whittle away more on m3core/src/unix Also some minor features I'll propose shortly. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 11:33:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > Quoting Jay K : > >> How does one checkout, update or commit to RC2 and beyond RC2? > > No changes here. I'd just like to avoid branching for the release, > and concentrate work on it. > >> There is still maybe the formsedit crash. I'll verify soon. >> >> Ideally we get to a situation in which distributions are built every >> day and what we ship is merely picked among them. I need to ever >> get Tinderbox working and under cron or in a loop. >> >> I also wonder if we should go back to 5.7.something, since we burned >> through 5.7 fairly fast. > > Please, let's just provide one stable official release, and not confuse > anybody by using old version numbers. > > Olaf > >> ---------------------------------------- >>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> CC: m3-support at elego.de >>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>> >>> Hi all, >>> >>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>> The reported compiler vesion will be d5.8.2 for this RC. >>> There seems to be a neverending stream of commits, which makes >>> it quite difficult to choose a good time to do this, but I hope >>> that Tinderbox will show no major problems with the tagged sources. >>> >>> I'd like everybody for the next weeks to postpone their functional >>> changes and concentrate on testing and fixing bugs that are found >>> or already known. If anybody knows of any problems with the current >>> tag we can still move it in places _before_ we build any release >>> archives. Tagging the whole repository is a quite costly operation >>> in CVS. >>> >>> To summarize: >>> >>> o refrain from functional changes >>> o report and correct bugs >>> o don't build any distribution archives until we've agreed we've >>> tagged a good source set >>> >>> I'll perform some testing myself and try to prepare a draft for the >>> release notes (a lot of changes occured in the recent years) within the >>> next days. >>> >>> Thanks for your patience and your contribution, >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 15 14:01:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 12:01:43 +0000 Subject: [M3devel] TARGET_OS, TARGET_PROCESSOR, TARGET_ENDIAN? Message-ID: I propose there be quake variables, set by by cm3 in Target.m3 with the possible names/values: TARGET_OS: ?TARGET_KERNEL, ?TARGET_LIBC (which /sort of/ makes sense but surely wouldn't be the conclusion) FREEBSD, NETBSD, OPENBSD, DARWIN, LINUX, SOLARIS, NT, CYGWIN, INETRIX, TRU64 (OSF1?), VMS, HPUX, IRIX, AIX, HERD?, GNUHERD?, GNU??, PLAN9?, MACOS?, DJGPP?, MSDOS? TARGET_PROCESSOR: ?TARGET_CPU, ?TARGET_ARCHITECTURE, ?TARGET_PROCESSOR_ARCHITECTURE I386, AMD64, SPARC, SPARC64, PPC, PPC64, ARM, MIPS, MIPS64, ALPHA, IA64, M68K?, SH3?, SH4? (I doubt these last three will ever be supported.) I grant that this is somewhat redundant with WORD_SIZE. You could just have X86, SPARC, PPC, MIPS, and dispense with AMD64, SPARC64, PPC64, MIPS64. TARGET_ENDIAN: BIG, LITTLE This would allow for much smoother maintenance of a few m3makefiles, since a lot of stuff keyed by TARGET need only be keyed by one of these factors. I also propose, maybe, there be similar HOST_ variables where above I have TARGET_. Though these have far less utility. If I didn't already introduce it, HOST_OSTYPE is about the right thing here -- POSIX or WIN32. I also put in HOST which draws from the same values as TARGET, really just as a default for TARGET when probing for config files. I also grant that I'm ignoring some harder to pin down problems such as "TARGET_ABI" -- 32bit MIPS has two, and IA64 has a surprising number -- there are actually 32bit ABIs on IA64_HPUX, we'd probably never support them. Ideally but not always, TARGET = TARGET_PROCESSOR + TARGET_OS? - Jay From wagner at elegosoft.com Wed Jul 15 16:01:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 16:01:23 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: <20090715160123.zrxx74tg2ssoc8cg@mail.elegosoft.com> Quoting Jay K : > I'd still like to: > > reduce the indirection in the recently introduced symlinks..it is > a small change (that's what I always say!) (though the movement from > pkg to lib I wouldn't call small) > > improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, > AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, > AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others > > These might be be mostly just: > - updating RTSignalC.c Minor corrections and improvements can still be made for the next release candidate (RC3), or release (if we agree that RC2 is OK ;-) > - updating the GNU configuration name for AMD64_SOLARIS in > m3cc/src/m3makefile > - fix my Python scripts to consume the master package list, > build m3gdb, build cm3ide, build in dependency order (huh, I thought > they always did, now not sure), add your feature of passing on > extra parameteres to cm3 > - maybe change the *.sh files to accept parameters in any order > like the *.py > - maybe whittle away more on m3core/src/unix > > Also some minor features I'll propose shortly. Well, we originally wanted to deliver a release (which has been overdue for many years) in May; now it's mid of July. There's always lots of stuff we can improve, but why not do it in the next release? We'll never get anything released if we continue adding new things... Olaf > ---------------------------------------- >> Date: Wed, 15 Jul 2009 11:33:56 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Quoting Jay K : >> >>> How does one checkout, update or commit to RC2 and beyond RC2? >> >> No changes here. I'd just like to avoid branching for the release, >> and concentrate work on it. >> >>> There is still maybe the formsedit crash. I'll verify soon. >>> >>> Ideally we get to a situation in which distributions are built every >>> day and what we ship is merely picked among them. I need to ever >>> get Tinderbox working and under cron or in a loop. >>> >>> I also wonder if we should go back to 5.7.something, since we burned >>> through 5.7 fairly fast. >> >> Please, let's just provide one stable official release, and not confuse >> anybody by using old version numbers. >> >> Olaf >> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: m3-support at elego.de >>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Hi all, >>>> >>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>> The reported compiler vesion will be d5.8.2 for this RC. >>>> There seems to be a neverending stream of commits, which makes >>>> it quite difficult to choose a good time to do this, but I hope >>>> that Tinderbox will show no major problems with the tagged sources. >>>> >>>> I'd like everybody for the next weeks to postpone their functional >>>> changes and concentrate on testing and fixing bugs that are found >>>> or already known. If anybody knows of any problems with the current >>>> tag we can still move it in places _before_ we build any release >>>> archives. Tagging the whole repository is a quite costly operation >>>> in CVS. >>>> >>>> To summarize: >>>> >>>> o refrain from functional changes >>>> o report and correct bugs >>>> o don't build any distribution archives until we've agreed we've >>>> tagged a good source set >>>> >>>> I'll perform some testing myself and try to prepare a draft for the >>>> release notes (a lot of changes occured in the recent years) within the >>>> next days. >>>> >>>> Thanks for your patience and your contribution, >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Wed Jul 15 18:14:45 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Wed, 15 Jul 2009 12:14:45 -0400 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> Message-ID: <4A5DC833.1E75.00D7.1@scires.com> Olaf: Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. I'll try to work on this tonight. Thanks for getting us to this stage in the process! Regards, Randy Coleburn >>> Olaf Wagner 7/15/2009 2:31 AM >>> Hi all, I'm currently tagging the source base with release_CM3_5_8_RC2. The reported compiler vesion will be d5.8.2 for this RC. .. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Wed Jul 15 18:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 16:24:49 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <4A5DC833.1E75.00D7.1@scires.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: I think from Olaf's response to my question, you just do a regular "update" with no special parameters. Can some/all of your applications be in the cm3 repository? - Jay ________________________________ > Date: Wed, 15 Jul 2009 12:14:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Olaf: > > > > Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. > > > > I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. > > > > I'll try to work on this tonight. > > > > Thanks for getting us to this stage in the process! > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/15/2009 2:31 AM>>> > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > ... From wagner at elegosoft.com Wed Jul 15 19:12:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 19:12:41 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: <20090715191241.ykphdt1we68ooccs@mail.elegosoft.com> Quoting Jay K : > > I think from Olaf's response to my question, you just do a regular > "update" with no special parameters. I just checked: there have been no commits since I laid the tag this morning, so the current head is still equal to release_CM3_5_8_RC2. Randy, I haven't got TurtoiseCVS here, but I'd guess you can specify the tag in the checkout of update dialogue. If you check out release_CM3_5_8_RC2, CVS will just make that tag `sticky' (remember it in your workspace) and not let you do any updates (since it is no branch). Jay, I really don't want to repress all your activities, I'd just like you to consider if they are really necessary for this release (candidate) or if they can wait some more days. As I said, we can still incorporate minor improvements by moving the tag, but once we build packages, we should not touch it any more. Everything else can of course go into RC3 as long as it does not challenge the stability. Does that sound OK? Olaf > Can some/all of your applications be in the cm3 repository? > > - Jay > > > ________________________________ >> Date: Wed, 15 Jul 2009 12:14:45 -0400 >> From: rcolebur at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> >> >> >> >> >> >> Olaf: >> >> >> >> Ok, so now that you have RC2, I suppose I need to update my local >> copy of the repository to match RC2, rebuild everything, and test >> my applications to see how it fares. >> >> >> >> I'm using TortoiseCVS. If I just do a CVS update, I get everything >> that has changed in the repository, so I need to do some >> investigating to see how to get just the RC2 stuff. >> >> >> >> I'll try to work on this tonight. >> >> >> >> Thanks for getting us to this stage in the process! >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Olaf Wagner 7/15/2009 2:31 AM>>> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> ... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Wed Jul 15 19:33:36 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Wed, 15 Jul 2009 13:33:36 -0400 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> Message-ID: <4A5DDAB0.1E75.00D7.1@scires.com> Jay, No, I can't put all of my applications into the repository because many of them are "works for hire" and the source code cannot be released to the public domain. Regards, Randy >>> Jay K 7/15/2009 12:24 PM >>> I think from Olaf's response to my question, you just do a regular "update" with no special parameters. Can some/all of your applications be in the cm3 repository? - Jay ________________________________ > Date: Wed, 15 Jul 2009 12:14:45 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Olaf: > > > > Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. > > > > I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. > > > > I'll try to work on this tonight. > > > > Thanks for getting us to this stage in the process! > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/15/2009 2:31 AM>>> > Hi all, > > I'm currently tagging the source base with release_CM3_5_8_RC2. > The reported compiler vesion will be d5.8.2 for this RC. > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Wed Jul 15 19:35:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 15 Jul 2009 19:35:01 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> Message-ID: <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> OK< I've done the first changes to RC2 myself now:-/ cvs commit -m 'consistently rename programs lex, yacc, tok, ext to klex, kyacc, ktok, kext' caltech-parser The following files have been changed: T caltech-parser/parserlib/kext/src/m3makefile T caltech-parser/parserlib/klex/src/m3makefile T caltech-parser/parserlib/ktok/src/m3makefile T caltech-parser/parserlib/kyacc/src/m3makefile T caltech-parser/parserlib/parserlib/src/parser.tmpl I think that change is justified as we do not want to ship competing yaccs and lexs again, that's rather surprising (not to say annoying). I'd suggest we'll wait another day for late fixes and then build the RC2 packages. Any comments/suggestions so far? Olaf Quoting Jay K : > I'd still like to: > > reduce the indirection in the recently introduced symlinks..it is > a small change (that's what I always say!) (though the movement from > pkg to lib I wouldn't call small) > > > improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, > AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, > AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others > > These might be be mostly just: > - updating RTSignalC.c > - updating the GNU configuration name for AMD64_SOLARIS in > m3cc/src/m3makefile > - fix my Python scripts to consume the master package list, > build m3gdb, build cm3ide, build in dependency order (huh, I thought > they always did, now not sure), add your feature of passing on > extra parameteres to cm3 > - maybe change the *.sh files to accept parameters in any order > like the *.py > - maybe whittle away more on m3core/src/unix > > Also some minor features I'll propose shortly. > > - Jay > > > > > > > > ---------------------------------------- >> Date: Wed, 15 Jul 2009 11:33:56 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> Quoting Jay K : >> >>> How does one checkout, update or commit to RC2 and beyond RC2? >> >> No changes here. I'd just like to avoid branching for the release, >> and concentrate work on it. >> >>> There is still maybe the formsedit crash. I'll verify soon. >>> >>> Ideally we get to a situation in which distributions are built every >>> day and what we ship is merely picked among them. I need to ever >>> get Tinderbox working and under cron or in a loop. >>> >>> I also wonder if we should go back to 5.7.something, since we burned >>> through 5.7 fairly fast. >> >> Please, let's just provide one stable official release, and not confuse >> anybody by using old version numbers. >> >> Olaf >> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: m3-support at elego.de >>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Hi all, >>>> >>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>> The reported compiler vesion will be d5.8.2 for this RC. >>>> There seems to be a neverending stream of commits, which makes >>>> it quite difficult to choose a good time to do this, but I hope >>>> that Tinderbox will show no major problems with the tagged sources. >>>> >>>> I'd like everybody for the next weeks to postpone their functional >>>> changes and concentrate on testing and fixing bugs that are found >>>> or already known. If anybody knows of any problems with the current >>>> tag we can still move it in places _before_ we build any release >>>> archives. Tagging the whole repository is a quite costly operation >>>> in CVS. >>>> >>>> To summarize: >>>> >>>> o refrain from functional changes >>>> o report and correct bugs >>>> o don't build any distribution archives until we've agreed we've >>>> tagged a good source set >>>> >>>> I'll perform some testing myself and try to prepare a draft for the >>>> release notes (a lot of changes occured in the recent years) within the >>>> next days. >>>> >>>> Thanks for your patience and your contribution, >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 15 20:35:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 18:35:30 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <4A5DDAB0.1E75.00D7.1@scires.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <4A5DC833.1E75.00D7.1@scires.com> <4A5DDAB0.1E75.00D7.1@scires.com> Message-ID: Understood, I had to ask just in case. (I was going to explain the various licenses but...) - Jay ________________________________ > Date: Wed, 15 Jul 2009 13:33:36 -0400 > From: rcolebur at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > > > > > > > Jay, > > > > No, I can't put all of my applications into the repository because many of them are "works for hire" and the source code cannot be released to the public domain. > > > > Regards, > > Randy > >>>> Jay K 7/15/2009 12:24 PM>>> > > I think from Olaf's response to my question, you just do a regular "update" with no special parameters. > > Can some/all of your applications be in the cm3 repository? > > - Jay > > > ________________________________ >> Date: Wed, 15 Jul 2009 12:14:45 -0400 >> From: rcolebur at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> >> >> >> >> >> >> Olaf: >> >> >> >> Ok, so now that you have RC2, I suppose I need to update my local copy of the repository to match RC2, rebuild everything, and test my applications to see how it fares. >> >> >> >> I'm using TortoiseCVS. If I just do a CVS update, I get everything that has changed in the repository, so I need to do some investigating to see how to get just the RC2 stuff. >> >> >> >> I'll try to work on this tonight. >> >> >> >> Thanks for getting us to this stage in the process! >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Olaf Wagner 7/15/2009 2:31 AM>>> >> Hi all, >> >> I'm currently tagging the source base with release_CM3_5_8_RC2. >> The reported compiler vesion will be d5.8.2 for this RC. >> .. From jay.krell at cornell.edu Wed Jul 15 20:37:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Jul 2009 18:37:10 +0000 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: Definitely these should be renamed from what they are. Does "kext" bother anyone else, enough to come up with another name? kext is the extension for "kernel extensions" on Darwin -- drivers. Maybe I can get one more change in in the day window. :) Or it can be in after the RC, ok. It's a very compatible and fairly desirable change, to shorten the symlink chain lengths. - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 19:35:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze > > OK< I've done the first changes to RC2 myself now:-/ > > cvs commit -m 'consistently rename programs lex, yacc, tok, ext to > klex, kyacc, ktok, kext' caltech-parser > > The following files have been changed: > T caltech-parser/parserlib/kext/src/m3makefile > T caltech-parser/parserlib/klex/src/m3makefile > T caltech-parser/parserlib/ktok/src/m3makefile > T caltech-parser/parserlib/kyacc/src/m3makefile > T caltech-parser/parserlib/parserlib/src/parser.tmpl > > I think that change is justified as we do not want to ship competing > yaccs and lexs again, that's rather surprising (not to say annoying). > > I'd suggest we'll wait another day for late fixes and then build > the RC2 packages. > Any comments/suggestions so far? > > Olaf > > Quoting Jay K : > >> I'd still like to: >> >> reduce the indirection in the recently introduced symlinks..it is >> a small change (that's what I always say!) (though the movement from >> pkg to lib I wouldn't call small) >> >> >> improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, >> AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, >> AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others >> >> These might be be mostly just: >> - updating RTSignalC.c >> - updating the GNU configuration name for AMD64_SOLARIS in >> m3cc/src/m3makefile >> - fix my Python scripts to consume the master package list, >> build m3gdb, build cm3ide, build in dependency order (huh, I thought >> they always did, now not sure), add your feature of passing on >> extra parameteres to cm3 >> - maybe change the *.sh files to accept parameters in any order >> like the *.py >> - maybe whittle away more on m3core/src/unix >> >> Also some minor features I'll propose shortly. >> >> - Jay >> >> >> >> >> >> >> >> ---------------------------------------- >>> Date: Wed, 15 Jul 2009 11:33:56 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; m3-support at elego.de >>> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>> >>> Quoting Jay K : >>> >>>> How does one checkout, update or commit to RC2 and beyond RC2? >>> >>> No changes here. I'd just like to avoid branching for the release, >>> and concentrate work on it. >>> >>>> There is still maybe the formsedit crash. I'll verify soon. >>>> >>>> Ideally we get to a situation in which distributions are built every >>>> day and what we ship is merely picked among them. I need to ever >>>> get Tinderbox working and under cron or in a loop. >>>> >>>> I also wonder if we should go back to 5.7.something, since we burned >>>> through 5.7 fairly fast. >>> >>> Please, let's just provide one stable official release, and not confuse >>> anybody by using old version numbers. >>> >>> Olaf >>> >>>> ---------------------------------------- >>>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> CC: m3-support at elego.de >>>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>>> >>>>> Hi all, >>>>> >>>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>>> The reported compiler vesion will be d5.8.2 for this RC. >>>>> There seems to be a neverending stream of commits, which makes >>>>> it quite difficult to choose a good time to do this, but I hope >>>>> that Tinderbox will show no major problems with the tagged sources. >>>>> >>>>> I'd like everybody for the next weeks to postpone their functional >>>>> changes and concentrate on testing and fixing bugs that are found >>>>> or already known. If anybody knows of any problems with the current >>>>> tag we can still move it in places _before_ we build any release >>>>> archives. Tagging the whole repository is a quite costly operation >>>>> in CVS. >>>>> >>>>> To summarize: >>>>> >>>>> o refrain from functional changes >>>>> o report and correct bugs >>>>> o don't build any distribution archives until we've agreed we've >>>>> tagged a good source set >>>>> >>>>> I'll perform some testing myself and try to prepare a draft for the >>>>> release notes (a lot of changes occured in the recent years) within the >>>>> next days. >>>>> >>>>> Thanks for your patience and your contribution, >>>>> >>>>> Olaf >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 15 21:08:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 15 Jul 2009 12:08:28 -0700 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: I meant to say from what they *were*. I only have to whine non zero about 'kext' I don't insist or such. What they *are* is fine. I was agreeing but accidentally disagreed. - oops (phone) On Jul 15, 2009, at 11:37 AM, Jay K wrote: > > Definitely these should be renamed from what they are. > Does "kext" bother anyone else, enough to come up with another name? > kext is the extension for "kernel extensions" on Darwin -- drivers. > > Maybe I can get one more change in in the day window. :) Or it can > be in after the RC, ok. It's a very compatible and fairly desirable > change, to shorten the symlink chain lengths. > > - Jay > > > ---------------------------------------- >> Date: Wed, 15 Jul 2009 19:35:01 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >> >> OK< I've done the first changes to RC2 myself now:-/ >> >> cvs commit -m 'consistently rename programs lex, yacc, tok, ext to >> klex, kyacc, ktok, kext' caltech-parser >> >> The following files have been changed: >> T caltech-parser/parserlib/kext/src/m3makefile >> T caltech-parser/parserlib/klex/src/m3makefile >> T caltech-parser/parserlib/ktok/src/m3makefile >> T caltech-parser/parserlib/kyacc/src/m3makefile >> T caltech-parser/parserlib/parserlib/src/parser.tmpl >> >> I think that change is justified as we do not want to ship competing >> yaccs and lexs again, that's rather surprising (not to say annoying). >> >> I'd suggest we'll wait another day for late fixes and then build >> the RC2 packages. >> Any comments/suggestions so far? >> >> Olaf >> >> Quoting Jay K : >> >>> I'd still like to: >>> >>> reduce the indirection in the recently introduced symlinks..it is >>> a small change (that's what I always say!) (though the movement from >>> pkg to lib I wouldn't call small) >>> >>> >>> improve the state of a few targets, esp. ARM_DARWIN, I386_SOLARIS, >>> AMD64_SOLARIS, maybe SPARC64_SOLARIS, SPARC64_OPENBSD, >>> AMD64_OPENBSD, AMD64_NETBSD, I386_OPENBSD, maybe others >>> >>> These might be be mostly just: >>> - updating RTSignalC.c >>> - updating the GNU configuration name for AMD64_SOLARIS in >>> m3cc/src/m3makefile >>> - fix my Python scripts to consume the master package list, >>> build m3gdb, build cm3ide, build in dependency order (huh, I thought >>> they always did, now not sure), add your feature of passing on >>> extra parameteres to cm3 >>> - maybe change the *.sh files to accept parameters in any order >>> like the *.py >>> - maybe whittle away more on m3core/src/unix >>> >>> Also some minor features I'll propose shortly. >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>>> Date: Wed, 15 Jul 2009 11:33:56 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com; m3-support at elego.de >>>> Subject: RE: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>> >>>> Quoting Jay K : >>>> >>>>> How does one checkout, update or commit to RC2 and beyond RC2? >>>> >>>> No changes here. I'd just like to avoid branching for the release, >>>> and concentrate work on it. >>>> >>>>> There is still maybe the formsedit crash. I'll verify soon. >>>>> >>>>> Ideally we get to a situation in which distributions are built >>>>> every >>>>> day and what we ship is merely picked among them. I need to ever >>>>> get Tinderbox working and under cron or in a loop. >>>>> >>>>> I also wonder if we should go back to 5.7.something, since we >>>>> burned >>>>> through 5.7 fairly fast. >>>> >>>> Please, let's just provide one stable official release, and not >>>> confuse >>>> anybody by using old version numbers. >>>> >>>> Olaf >>>> >>>>> ---------------------------------------- >>>>>> Date: Wed, 15 Jul 2009 08:31:40 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: m3devel at elegosoft.com >>>>>> CC: m3-support at elego.de >>>>>> Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm currently tagging the source base with release_CM3_5_8_RC2. >>>>>> The reported compiler vesion will be d5.8.2 for this RC. >>>>>> There seems to be a neverending stream of commits, which makes >>>>>> it quite difficult to choose a good time to do this, but I hope >>>>>> that Tinderbox will show no major problems with the tagged >>>>>> sources. >>>>>> >>>>>> I'd like everybody for the next weeks to postpone their >>>>>> functional >>>>>> changes and concentrate on testing and fixing bugs that are found >>>>>> or already known. If anybody knows of any problems with the >>>>>> current >>>>>> tag we can still move it in places _before_ we build any release >>>>>> archives. Tagging the whole repository is a quite costly >>>>>> operation >>>>>> in CVS. >>>>>> >>>>>> To summarize: >>>>>> >>>>>> o refrain from functional changes >>>>>> o report and correct bugs >>>>>> o don't build any distribution archives until we've agreed we've >>>>>> tagged a good source set >>>>>> >>>>>> I'll perform some testing myself and try to prepare a draft for >>>>>> the >>>>>> release notes (a lot of changes occured in the recent years) >>>>>> within the >>>>>> next days. >>>>>> >>>>>> Thanks for your patience and your contribution, >>>>>> >>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>> Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz >>>> : Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be >> rlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> From eiserlohpp at yahoo.com Thu Jul 16 03:19:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 15 Jul 2009 18:19:49 -0700 (PDT) Subject: [M3devel] M3Config contains paths to installation directory. Message-ID: <645960.77867.qm@web56801.mail.re3.yahoo.com> Hi Jay, Do you know of any way to tell the build system that the final installation directory is located in one place, but that the software is to actually be shipped (temporarily) to a staging directory. Specifically, libm3/src/config contains a m3makefile that derives the M3Config interface, containing a number of paths to the installation root directory. This is the normal situation for most people, but I am installing to a temporary directory, for packaging purposes. The packaging software later installs the package into the correct location. Whenever I build the system, M3Config always contains the paths to my staging area. I would like some way of specifying to the build system that the final (or real) installation root is one thing, but "ship" would actually install into a different one. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Thu Jul 16 04:46:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 02:46:35 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: 1) I do wonder if this is what PKG_USE vs. PKG_INSTALL is but not sure. 2) You can achieve your goal easily anyway? Like, stick -R/usr/local/lib in the right place? Appropriately generalized? That is -- introduce another variable, DESTDIR? I content that we have significant/complete control of all the config files, so you can feel able to go into m3-sys/cminstall/src/config-no-install and sprinkle like DESTDIR="/usr/local/cm3" into all the files, or just into cm3cfg.common. 3) Can you just avoid knowing it? > libm3/src/config Hm. Maybe we examine it, deem it "problematic", and reduce or remove its functionality, such as to eliminate your problem? Assume there aren't many users and watch for the fallout? Or maybe, and again, I have to look at it, but maybe whatever data is exposed here can be computed at runtime instead of build-time, assuming dynamic linking to libm3core.so? In Windows it is easy enough for some code at runtime to gets the path to the file (.exe, .dll) it is in. Other systems? So I think, using that, this interface can generate the data at runtime instead of build-time. Which may or maybe be what you want -- the "official " or "default" install location, or the actual "current" location? - Jay ---------------------------------------- > Date: Wed, 15 Jul 2009 18:19:49 -0700 > From: eiserlohpp at yahoo.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] M3Config contains paths to installation directory. > > > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Thu Jul 16 05:25:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 03:25:48 +0000 Subject: [M3devel] how to port to new target Message-ID: "how to port" I know there is a web already but maybe it needs updating. (Maybe not, basically just one item stricken/reduced). Based on the AMD64_NETBSD/OPENBSD work (ChangeLog entry), and /assuming/ gcc has already been ported, here is a/the specific current list of files that need visiting for porting: add a file to m3-sys/cminstall/src/config-no-install m3-sys/m3middle/src/Target.m3 m3-sys/m3middle/src/Target.i3 (trivial, just add to the list) m3-libs/m3core/src/runtime/common/Compiler.tmpl (trivial) add m3-libs/m3core/src/C/TARGET/Csetjmp.i3 (redundant with Target.m3) add m3-libs/m3core/src/C/TARGET/m3makefile (trivial, always the same) all these trivial: m3-libs/m3core/src/thread.quake m3-libs/libm3/src/os/POSIX/m3makefile m3-libs/libm3/src/random/m3makefile m3-libs/m3core/src/C/Common/m3makefile m3-libs/m3core/src/Csupport/m3makefile m3-libs/m3core/src/float/m3makefile m3-libs/m3core/src/runtime/m3makefile m3-libs/m3core/src/runtime/POSIX/m3makefile m3-libs/m3core/src/runtime/common/m3makefile m3-libs/m3core/src/time/POSIX/m3makefile m3-libs/m3core/src/unix/Common/m3makefile plus off the top of my head: scripts/sysinfo.sh -- platform detection using uname etc. scripts/python/pylib.py -- platform detection and possible changes to "boot" (redundant with config file sorry) m3-sys/m3cc/src/m3makefile -- at least add the TARGET => GNU_PLATFORM mapping for building a cross compiler; sometimes more is needed m3-sys/m3gdb/src/m3makefile -- ditto m3-libs/m3core/src/runtime/POSIX/RTSignalC.c for adding a new processor for Solaris or NetBSD, maybe already portable, but otherwise this file is highly target specific, though you can also just fallback and return 0. I'd rather not put in the fallback, lest porters don't get a "reminder". They can always make it so upon being reminded. (The reminder comes unfortunately late -- when native building the boot archive on the target platform.) plus some possible revisitation of: m3-libs/m3core/src/unix/Common but often just works. Adding a new processor for Darwin is a little different than other platforms. Threading is a little different, in a good way and you might to use Apple's fork of gcc (see m3cc/m3makefile, look for ARM_DARWIN). In future maybe things go a little different, like if there are more builtin backends or stack walkers. (Though I'm hoping for a fairly portable stack walker using libgcc/libunwind.) It should be possible to significantly reduce this if you are only adding another processor for an existing OS, or just another OS for existing processor. A lot of the checks only depend on endian or OS. Granted it is not a long list asis. If there is non-Posix non-NT platform, more work. - Jay From rodney.m.bates at cox.net Thu Jul 16 02:30:14 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 15 Jul 2009 19:30:14 -0500 Subject: [M3devel] Release notes comments Message-ID: <4A5E7496.7020308@cox.net> A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. From wagner at elegosoft.com Thu Jul 16 08:24:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 08:24:22 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <4A5E7496.7020308@cox.net> References: <4A5E7496.7020308@cox.net> Message-ID: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Quoting "Rodney M. Bates" : > A couple of comments on the release notes for 5.8.2:
  • System > pthread threading is now the default on all > platforms. The original (fast) M3 user level thread code is > still there and can be used if necessary (on most platforms). On > many systems, this allows M3 applications to scale over all > available hardware processors.
  • > > This sounds like it is the original user level threads that allow > scaling over multiple processors, which I believe is backwards. I > suggest swapping the second and third sentences be for clarity. >
  • New data type LONGINT (64 bit integer) on all target > platforms except Windows (still in the queue).
  • > > As I understand it, LONGINT is in Windows too, it just isn't 64 > bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 16 08:44:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 08:44:14 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> Please remind me again what exactly depends on this interface and why we do it that way. In cm3 I find quake variables like these (* Default to a native build, so the config file can say less. *) Quake.Define(mach, "TARGET", M3Config.TARGET); Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); Quake.Define(mach, "BACKEND_MODE", Version.BackendMode); Quake.Define(mach, "C_COMPILER", Version.CCompiler); Quake.Define(mach, "LINKER", Version.Linker); Quake.Define(mach, "THREAD_LIBRARY", Version.ThreadLibrary); Quake.Define(mach, "WINDOW_LIBRARY", Version.WindowLibrary); Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); (* Even if the config file overrides the defaults, such as to do a cross build, the host characteristics are still available. *) Quake.Define(mach, "HOST", M3Config.TARGET); Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); but no installation paths. Most code uses MxConfig AS M3Config. I see it's used in m3browser as package_root deault, but that can surely be fixed and it can also be specified on the command line. Same in m3tohtml. So why is it needed? One obvious way to overcome Peter's problem would of course be to pass a parameter block to quake when building ("m3config-overrides"?). Better perhaps to get rid of these paths. Olaf Quoting Peter Eiserloh : > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 16 09:43:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 07:43:22 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <20090716084414.vmrcjunqgo0gso4k@mail.elegosoft.com> Message-ID: I'm pretty confident we can fix this fairly soon. Many M3Config users can/should be replaced with MxConfig. MxConfig can be augmented with "static" things like OS_TYPE, PATH_SEP. Capturing stuff like PKG_USE at compile time is quite bogus, except as part of some sort of "cm3 -v" like how gcc reports its configure command line. But that wouldn't be in a public interface. Can anyone confirm the theory I just invented as to the history here? M3Config existed. M3Config was recognized as broken. MxConfig introduced as a replacement for M3Config. This "AS" construct I see used rarely, makes me thing something a little unusual afoot here, and "getting something very wrong the first time" seems to be unusual in M3. :) Doing the same grep that Olaf did... C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(177): CopyTextArray(self.options.addSearchDir,M3Config.PKG_USE & broken C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(178): M3Config.PATH_SEP & "sgml" & M3Config.PATH_SEP & "src" & C:\dev2\cm3.2\m3-libs\sgml\src\SGML.m3(179): M3Config.PATH_SEP & "dtd"); ok, augment MxConfig with this data C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(57): env := NewEnv("target", NewText(M3Config.TARGET), env); C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(58): env := NewEnv("osType", NewText(M3Config.OS_TYPE), env); C:\dev2\cm3.2\m3-obliq\obliqrt\src\Obliq.m3(59): env := NewEnv("pathSep", NewText(M3Config.PATH_SEP), env); ditto C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, "TARGET", M3Config.TARGET); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, "HOST", M3Config.TARGET); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); I put all these in and they are all ok, but also ditto. (The idea being we end up with only MxConfig and no M3Config.) C:\dev2\cm3.2\m3-sys\cm3ide\src\misc\Default.m3(35): build_dir := M3Config.Get ("BUILD_DIR"); C:\dev2\cm3.2\m3-sys\cm3ide\src\misc\Default.m3(36): system_root := M3Config.Get ("PKG_USE"); (* note: system_root is the public package root *) These are all really MxConfig, everything in this file, ok. C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(22): SLASH = M3Config.PATH_SEP; ok C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(31): package_root := M3Config.PKG_USE; broken C:\dev2\cm3.2\m3-tools\m3browser\src\Main.m3(37): derived_dirs := IntList.List1 (ID.Add (M3Config.BUILD_DIR)); slightly broken C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(137): pkgRoot := M3Config.PKG_USE; broken C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(243): proj_pkg := pkgRoot & M3Config.PATH_SEP & pkg; ok C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(281): IF Text.GetChar (filename, i) # Text.GetChar (M3Config.BUILD_DIR, i) THEN slightly broken, BUILD_DIR is not necessarily TARGET, though if/when we provide CM3_OUTPUT_ROOT, BUILD_DIR can go away, or just be really synonymous with TARGET. C:\dev2\cm3.2\m3-tools\m3tohtml\src\Main.m3(287): IF Text.GetChar (filename, i) = Text.GetChar (M3Config.PATH_SEP, 0) THEN ok C:\dev2\cm3.2\m3-tools\m3tohtml\src\Msg.m3(38): IF Text.Equal(M3Config.OS_TYPE, "WIN32") THEN ok, but there is a better way, something like Wr.EOL or OSConfig.LineSep, which are completely redundant, and Wr.EOL ideally would be a constant. later.. - Jay > Date: Thu, 16 Jul 2009 08:44:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > Please remind me again what exactly depends on this interface > and why we do it that way. > > In cm3 I find quake variables like these > > (* Default to a native build, so the config file can say less. *) > > Quake.Define(mach, "TARGET", M3Config.TARGET); > Quake.Define(mach, "OS_TYPE", M3Config.OS_TYPE); > Quake.Define(mach, "BACKEND_MODE", Version.BackendMode); > Quake.Define(mach, "C_COMPILER", Version.CCompiler); > Quake.Define(mach, "LINKER", Version.Linker); > Quake.Define(mach, "THREAD_LIBRARY", Version.ThreadLibrary); > Quake.Define(mach, "WINDOW_LIBRARY", Version.WindowLibrary); > Quake.Define(mach, "WORD_SIZE", M3Config.WORD_SIZE); > > (* Even if the config file overrides the defaults, such as to do > a cross build, the host characteristics are still available. *) > > Quake.Define(mach, "HOST", M3Config.TARGET); > Quake.Define(mach, "HOST_OS_TYPE", M3Config.OS_TYPE); > Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); > > but no installation paths. Most code uses MxConfig AS M3Config. > > I see it's used in m3browser as package_root deault, but that can surely > be fixed and it can also be specified on the command line. > Same in m3tohtml. So why is it needed? > > One obvious way to overcome Peter's problem would of course be > to pass a parameter block to quake when building ("m3config-overrides"?). > Better perhaps to get rid of these paths. > > Olaf > > Quoting Peter Eiserloh : > > > Hi Jay, > > > > Do you know of any way to tell the build system that the > > final installation directory is located in one place, but > > that the software is to actually be shipped (temporarily) > > to a staging directory. > > > > Specifically, libm3/src/config contains a m3makefile that > > derives the M3Config interface, containing a number of > > paths to the installation root directory. > > > > This is the normal situation for most people, but I am > > installing to a temporary directory, for packaging purposes. > > The packaging software later installs the package into > > the correct location. > > > > Whenever I build the system, M3Config always contains > > the paths to my staging area. > > > > I would like some way of specifying to the build system > > that the final (or real) installation root is one thing, > > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh | > > +--------------------------------------------------------+ > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 16 14:57:05 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 14:57:05 +0200 Subject: [M3devel] how to port to new target In-Reply-To: References: Message-ID: <20090716145705.vc4lzxbu8oo8kskk@mail.elegosoft.com> How about updating http://www.opencm3.net/porting.html? This mail will be much more difficult to find later... Olaf Quoting Jay K : > "how to port" > > I know there is a web already but maybe it needs updating. (Maybe > not, basically just one item stricken/reduced). > > > Based on the AMD64_NETBSD/OPENBSD work (ChangeLog entry), and /assuming/ > gcc has already been ported, here is a/the specific > current list of files that need visiting for porting: > > > add a file to m3-sys/cminstall/src/config-no-install > m3-sys/m3middle/src/Target.m3 > m3-sys/m3middle/src/Target.i3 (trivial, just add to the list) > m3-libs/m3core/src/runtime/common/Compiler.tmpl (trivial) > > > add m3-libs/m3core/src/C/TARGET/Csetjmp.i3 (redundant with Target.m3) > add m3-libs/m3core/src/C/TARGET/m3makefile (trivial, always the same) > > > all these trivial: > m3-libs/m3core/src/thread.quake > m3-libs/libm3/src/os/POSIX/m3makefile > m3-libs/libm3/src/random/m3makefile > m3-libs/m3core/src/C/Common/m3makefile > m3-libs/m3core/src/Csupport/m3makefile > m3-libs/m3core/src/float/m3makefile > m3-libs/m3core/src/runtime/m3makefile > m3-libs/m3core/src/runtime/POSIX/m3makefile > m3-libs/m3core/src/runtime/common/m3makefile > m3-libs/m3core/src/time/POSIX/m3makefile > m3-libs/m3core/src/unix/Common/m3makefile > > > plus off the top of my head: > scripts/sysinfo.sh -- platform detection using uname etc. > scripts/python/pylib.py -- platform detection and possible changes > to "boot" (redundant with config file sorry) > m3-sys/m3cc/src/m3makefile -- at least add the TARGET => GNU_PLATFORM > mapping for building a cross compiler; sometimes more is needed > m3-sys/m3gdb/src/m3makefile -- ditto > m3-libs/m3core/src/runtime/POSIX/RTSignalC.c > for adding a new processor for Solaris or NetBSD, maybe already portable, > but otherwise this file is highly target specific, though you can > also just fallback and return 0. > I'd rather not put in the fallback, > lest porters don't get a "reminder". > They can always make it so upon being reminded. > (The reminder comes unfortunately late -- when native building > the boot archive on the target platform.) > > > plus some possible revisitation of: > m3-libs/m3core/src/unix/Common but > often just works. > > > Adding a new processor for Darwin is a > little different than other platforms. > Threading is a little different, in a good > way and you might to use Apple's fork of gcc (see > m3cc/m3makefile, look for ARM_DARWIN). > > > In future maybe things go a little different, > like if there are more builtin backends > or stack walkers. (Though I'm hoping for > a fairly portable stack walker using libgcc/libunwind.) > > > It should be possible to significantly reduce > this if you are only adding another processor > for an existing OS, or just another > OS for existing processor. > > > A lot of the checks only depend on endian or OS. > Granted it is not a long list asis. > > > If there is non-Posix non-NT platform, more work. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 16 15:05:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Jul 2009 15:05:58 +0200 Subject: [M3devel] HEADS UP: release_CM3_5_8_RC2 / code freeze In-Reply-To: References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> Message-ID: <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I meant to say from what they *were*. I only have to whine non zero > about 'kext' I don't insist or such. What they *are* is fine. I was > agreeing but accidentally disagreed. I thought as much. > - oops (phone) > > On Jul 15, 2009, at 11:37 AM, Jay K wrote: > >> Definitely these should be renamed from what they are. >> Does "kext" bother anyone else, enough to come up with another >> name? kext is the extension for "kernel extensions" on Darwin -- >> drivers. I didn't think of that, but I don't think it matters; there is no program named kext on Darwin, is there? >> Maybe I can get one more change in in the day window. :) Or it can >> be in after the RC, ok. It's a very compatible and fairly desirable >> change, to shorten the symlink chain lengths. If it's easy and won't break anything, go ahead. I'd like to build some packages by the end of this week. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Jul 16 16:39:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Jul 2009 10:39:03 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Message-ID: <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non- optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> A couple of comments on the release notes for 5.8.2:
  • System >> pthread threading is now the default on all >> platforms. The original (fast) M3 user level thread code is >> still there and can be used if necessary (on most platforms). On >> many systems, this allows M3 applications to scale over all >> available hardware processors.
  • >> >> This sounds like it is the original user level threads that allow >> scaling over multiple processors, which I believe is backwards. I >> suggest swapping the second and third sentences be for clarity. >>
  • New data type LONGINT (64 bit integer) on all target >> platforms except Windows (still in the queue).
  • >> >> As I understand it, LONGINT is in Windows too, it just isn't 64 >> bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for > several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least > some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in > source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 16 19:39:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 16 Jul 2009 13:39:29 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090630175228.GA16767@topoi.pooq.com> References: <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> <20090630175228.GA16767@topoi.pooq.com> Message-ID: <20090716173929.GB9087@topoi.pooq.com> On Tue, Jun 30, 2009 at 01:52:28PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: > > > > If it now just works and the problem cannot be reproduced, we should > > leave it that way. I wouldn't invest much time on chasing down such > > a spurious error now. > > OK. I'll take a look at installation instructions for some of the other > packages, such as the one with Trestle. > > -- hendrik Installed the collection m3gdb from archive cm3-bin-ws-m3gdb-LINUXLIBC6-d5.8.1-RC1.tgz; it installed flawlessly on Debian squeeze (32-bit intel). Did the same for m3gui, had a glitch. It's at the end of the shell log below. I've provided the entire log, starting with untarring the archive, in case you need context. -- hendrik hendrik at notlookedfor:~/cm3/collection-gui$ tar -zxf cm3-bin-ws-gui-LINUXLIBC6-d5.8.1-RC1.tgz hendrik at notlookedfor:~/cm3/collection-gui$ ls cm3-bin-ws-gui-LINUXLIBC6-d5.8.1-RC1.tgz install.sh m3-tools m3-win collection-gui.html m3-comm m3-ui hendrik at notlookedfor:~/cm3/collection-gui$ ./install.sh --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 .M3EXPORTS libm3tcp.so.5 libm3tcp.so libm3tcp.a libm3tcp.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/tcp/src/POSIX TCP.m3 TCPPosix.i3 Herrno.i3 HerrnoC.c IP.m3 IPErrorPosix.m3 TCPExtras.m3 TCPPeer.m3 TCPHack.i3 TCPHackNull.m3 ../src/common => /usr/local/cm3/pkg/tcp/src/common TCP.i3 IP.i3 TCPExtras.i3 TCPPeer.i3 IPError.i3 IPError.m3 StreamRd.i3 StreamRdClass.m3 StreamRdClass.i3 StreamWr.i3 StreamWrClass.i3 StreamWrClass.m3 TCPSpecial.i3 TCPMisc.i3 ConnFD.i3 ConnRW.i3 ConnRW.m3 ConnMsgRW.i3 ConnMsgRW.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/X11R4/LINUXLIBC6 .M3EXPORTS libm3X11R4.so.5 libm3X11R4.a libm3X11R4.m3x .M3WEB ../src/Vanilla => /usr/local/cm3/pkg/X11R4/src/Vanilla XMachine.i3 ../src/Common => /usr/local/cm3/pkg/X11R4/src/Common X.i3 Xatom.i3 Xmbuf.i3 Xct.i3 Xmu.i3 Xrm.i3 Xt.i3 XtC.m3 XtC.i3 XtE.i3 XtE.m3 XtN.i3 XtN.m3 XtR.i3 XtR.m3 Xaw.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/ui/LINUXLIBC6 .M3EXPORTS libm3ui.so.5 libm3ui.a libm3ui.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/ui/LINUXLIBC6 ComplSeq.i3 ComplSeq.m3 ComplSeqRep.i3 STypeMapSeq.m3 STypeMapSeq.i3 STypeMapSeqRep.i3 CompletionSeq.m3 CompletionSeq.i3 CompletionSeqRep.i3 ../src/xvbt => /usr/local/cm3/pkg/ui/src/xvbt Compl.i3 Compl.m3 XExtensions.i3 XExtensions.m3 XImUtil.i3 TrslOnXF.i3 XShm.i3 XClientExt.i3 XPicture.m3 XPicture.i3 XSharedMem.i3 XSharedMem.m3 XPictureFree.m3 XSharedFree.m3 PictureImpl.m3 XClient.m3 XClient.i3 XEventQueue.i3 XEventQueue.m3 XScreenType.i3 XScreenType.m3 XScrollQueue.m3 XScrollQueue.i3 XAtomQueue.m3 XAtomQueue.i3 XMessenger.i3 XMessenger.m3 XPaint.i3 XPaint.m3 XInput.i3 XInput.m3 XProperties.i3 XProperties.m3 XClientF.i3 XClientF.m3 XGC.m3 XGC.i3 XScrnTpRep.i3 XScrnTpRep.m3 XScrnCrsr.i3 XScrnCrsr.m3 XScrnCmap.m3 XScrnCmap.i3 XScrnFont.i3 XScrnFont.m3 XScrnPntOp.i3 XScrnPntOp.m3 XScrnPxmp.m3 XScrnPxmp.i3 XCursors.i3 XConfCtl.i3 XConfCtl.m3 TrestleOnX.i3 TrestleOnX.m3 TrestleOS.m3 ../src/vbt => /usr/local/cm3/pkg/ui/src/vbt Latin1Key.i3 KeyboardKey.i3 Trestle.i3 TrestleComm.i3 VBTTuning.i3 BatchRep.i3 PaintExt.i3 PlttFrnds.m3 PlttFrnds.i3 VBT.m3 VBT.i3 VBTClass.i3 VBTClass.m3 Batch.i3 Batch.m3 PaintPrivate.m3 PaintPrivate.i3 VBTRep.m3 VBTRep.i3 TrestleClass.m3 TrestleClass.i3 ScrnPixmap.m3 ScrnPixmap.i3 ScrnColorMap.i3 ScrnColorMap.m3 BatchUtil.i3 BatchUtil.m3 ScrnCursor.m3 ScrnCursor.i3 ScrnFont.i3 ScrnFont.m3 ScrnPaintOp.i3 ScrnPaintOp.m3 PaintOp.m3 PaintOp.i3 Palette.m3 Palette.i3 Font.i3 Font.m3 Cursor.i3 Cursor.m3 Pixmap.m3 Pixmap.i3 ScreenType.m3 ScreenType.i3 MouseSplit.m3 MouseSplit.i3 MiscDetail.m3 MiscDetail.i3 ../src/split => /usr/local/cm3/pkg/ui/src/split BtnVBTClass.i3 TextVBTClass.i3 BdrVBTClass.i3 STypeMap.i3 ComposeKey.m3 ComposeKey.i3 TranslateVBT.m3 TranslateVBT.i3 DblBufferVBT.i3 DblBufferVBT.m3 DblBufferUtil.m3 DblBufferUtil.i3 BorderedVBT.i3 BorderedVBT.m3 FilterClass.m3 FilterClass.i3 HVSplit.i3 HVSplit.m3 ZSplit.i3 ZSplit.m3 TSplit.i3 TSplit.m3 ButtonVBT.i3 ButtonVBT.m3 MenuBtnVBT.i3 MenuBtnVBT.m3 AnchorBtnVBT.i3 AnchorBtnVBT.m3 PackSplit.m3 PackSplit.i3 ProperSplit.i3 ProperSplit.m3 TextVBT.i3 TextVBT.m3 HVBar.i3 HVBar.m3 HighlightVBT.i3 HighlightVBT.m3 QuickBtnVBT.i3 QuickBtnVBT.m3 RigidVBT.m3 RigidVBT.i3 TextureVBT.i3 TextureVBT.m3 Split.i3 Split.m3 Filter.i3 Filter.m3 TypeInVBT.m3 TypeInVBT.i3 StableVBT.m3 StableVBT.i3 Gray.m3 Gray.i3 TwoTone.m3 TwoTone.i3 JoinedVBT.m3 JoinedVBT.i3 JoinParent.m3 JoinParent.i3 JoinScreen.i3 JoinScreen.m3 JoinCMap.m3 JoinCMap.i3 JoinCursor.i3 JoinCursor.m3 JoinFont.m3 JoinFont.i3 JoinPixmap.i3 JoinPixmap.m3 JoinPaintOp.i3 JoinPaintOp.m3 ETAgent.i3 ETAgent.m3 SelectQueue.m3 SelectQueue.i3 OverlayVBT.m3 OverlayVBT.i3 ../src/trestle => /usr/local/cm3/pkg/ui/src/trestle TrestleOS.i3 Trestle.m3 TrestleImpl.i3 InstallQueue.m3 InstallQueue.i3 DpyFilter.m3 DpyFilter.i3 TrestleGoo.i3 TrestleGoo.m3 InstalledVBT.i3 InstalledVBT.m3 TrestleConf.i3 ../src/picture => /usr/local/cm3/pkg/ui/src/picture Completion.m3 Completion.i3 Picture.m3 Picture.i3 PictureRep.i3 FreeList.mg --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/vbtkit/LINUXLIBC6 .M3EXPORTS libm3vbtkit.so.5 libm3vbtkit.a libm3vbtkit.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/vbtkit/LINUXLIBC6 VBTKitBundle.i3 VBTKitBundle.m3 ../src/lego/POSIX => /usr/local/cm3/pkg/vbtkit/src/lego/POSIX ScrollerVBTClass.m3 ZChassisVBT.m3 ../src/lego => /usr/local/cm3/pkg/vbtkit/src/lego AnchorSplit.i3 AnchorSplit.m3 AnchorHelpSplit.i3 AnchorHelpSplit.m3 AnchorHelpVBT.i3 AnchorHelpVBT.m3 BiFeedbackVBT.i3 BiFeedbackVBT.m3 BooleanVBT.i3 BooleanVBT.m3 ChoiceVBT.m3 ChoiceVBT.i3 FeedbackVBT.m3 FeedbackVBT.i3 FileBrowserVBT.i3 FileBrowserVBT.m3 FlexVBT.i3 FlexVBT.m3 GuardedBtnVBT.i3 GuardedBtnVBT.m3 Image.m3 Image.i3 ListVBT.i3 ListVBT.m3 MarginFeedbackVBT.i3 MarginFeedbackVBT.m3 MenuSwitchVBT.i3 MenuSwitchVBT.m3 MultiFilter.i3 MultiFilter.m3 MultiSplit.i3 MultiSplit.m3 MultiClass.i3 MultiClass.m3 NumericVBT.i3 NumericVBT.m3 OffsetVBT.i3 OffsetVBT.m3 PixmapVBT.i3 PixmapVBT.m3 QuickSwitchVBT.i3 QuickSwitchVBT.m3 ReactivityVBT.i3 ReactivityVBT.m3 ScaleFilter.i3 ScaleFilter.m3 ScrollerVBT.i3 ScrollerVBT.m3 ScrollerVBTClass.i3 Shadow.i3 Shadow.m3 ShadowPaint.i3 ShadowPaint.m3 ShadowedBarVBT.i3 ShadowedBarVBT.m3 ShadowedFeedbackVBT.m3 ShadowedFeedbackVBT.i3 ShadowedVBT.m3 ShadowedVBT.i3 SourceVBT.i3 SourceVBT.m3 SplitterVBT.i3 SplitterVBT.m3 SwitchVBT.i3 SwitchVBT.m3 TrillSwitchVBT.i3 TrillSwitchVBT.m3 VBTKitResources.i3 VBTKitResources.m3 ViewportVBT.i3 ViewportVBT.m3 ZBackgroundVBT.i3 ZBackgroundVBT.m3 ZChassisVBT.i3 ZChildVBT.i3 ZChildVBT.m3 ZGrowVBT.i3 ZGrowVBT.m3 ZMoveVBT.i3 ZMoveVBT.m3 ZSplitUtils.i3 ZSplitUtils.m3 ZTilps.i3 ZTilps.m3 ../src/vbtkitutils/POSIX => /usr/local/cm3/pkg/vbtkit/src/vbtkitutils/POSIX VBTKitEnv.i3 ../src/vbtkitutils => /usr/local/cm3/pkg/vbtkit/src/vbtkitutils AnyEvent.m3 AnyEvent.i3 AutoRepeat.i3 AutoRepeat.m3 LargeCursor.i3 LargeCursor.m3 Pts.i3 Pts.m3 Rsrc.i3 Rsrc.m3 VBTColors.i3 VBTColors.m3 VBTKitEnv.m3 XParam.m3 XParam.i3 XTrestle.i3 XTrestle.m3 ../src/etext => /usr/local/cm3/pkg/vbtkit/src/etext ISOChar.i3 ISOChar.m3 Key.i3 Key.m3 KeyFilter.m3 KeyFilter.i3 KeyTrans.i3 KeyTrans.m3 MTextUnit.i3 MTextUnit.m3 TextEditVBT.i3 TextEditVBT.m3 TextPort.i3 TextPort.m3 TextPortClass.m3 TextPortClass.i3 TypeinVBT.i3 TypeinVBT.m3 TypescriptVBT.i3 TypescriptVBT.m3 IvyModel.m3 IvyModel.i3 EmacsModel.i3 EmacsModel.m3 XtermModel.i3 XtermModel.m3 MacModel.m3 MacModel.i3 ../src/vtext => /usr/local/cm3/pkg/vbtkit/src/vtext VTDef.i3 VTextDef.i3 VText.i3 VText.m3 VT.i3 VT.m3 VTBase.i3 VTBase.m3 VTCaret.m3 VTCaret.i3 VTInterval.i3 VTInterval.m3 VTMarker.i3 VTMarker.m3 VTPounce.m3 VTPounce.i3 VTRd.i3 VTRd.m3 VTReal.i3 VTReal.m3 VTTexture.m3 VTTexture.i3 VTView.i3 VTView.m3 VTVirtual.i3 VTVirtual.m3 VTextRegion.m3 VTextRegion.i3 ../src/mtext => /usr/local/cm3/pkg/vbtkit/src/mtext MText.i3 MText.m3 MTextRd.i3 MTextRd.m3 MTextPrivate.i3 MTextDs.i3 MTextDs.m3 MTextDebug.i3 MTextDebug.m3 ../src/color => /usr/local/cm3/pkg/vbtkit/src/color Color.m3 Color.i3 ColorName.i3 ColorName.m3 ColorNameF.i3 ColorNameTable.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/cmvbt/LINUXLIBC6 .M3EXPORTS libcmvbt.so.5 libcmvbt.a libcmvbt.m3x .M3WEB ../src => /usr/local/cm3/pkg/cmvbt/src IntervalTimer.i3 IntervalTimer.m3 TabVBT.i3 TabVBT.m3 IPTypeinVBT.m3 IPTypeinVBT.i3 FrameVBT.i3 FrameVBT.m3 HoverVBT.i3 HoverVBT.m3 PasswordFont.m3 PasswordFont.i3 GridSplit.i3 GridSplit.m3 TableVBT.i3 TableVBT.m3 SortedTableVBT.m3 SortedTableVBT.i3 AnimateVBT.i3 AnimateVBT.m3 ClockVBT.i3 ClockVBT.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/jvideo/LINUXLIBC6 .M3EXPORTS libjvideo.so.5 libjvideo.a libjvideo.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/jvideo/src/POSIX JVBuffer.i3 JVSink.i3 Jv.i3 Jvs.m3 Jvs.i3 Jva.i3 Jva.m3 JvsProtocol.i3 JvaProtocol.i3 jvprotocol.i3 JvsBuffer.i3 JVFromSource.i3 JVFromSource.m3 JVFromDecomp.m3 JVFromDecomp.i3 JVConverter.m3 JVConverter.i3 JVConverterF.i3 JVDecomp.i3 JVDecomp.m3 JVAudio.i3 JVAudio.m3 JVSinkPool.m3 JVSinkPool.i3 JVDecompPool.i3 JVDecompPool.m3 ../src/POSIX/generic => /usr/local/cm3/pkg/jvideo/src/POSIX/generic JVBuffer.m3 JVSink.m3 Jv.m3 JvsBuffer.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/videovbt/LINUXLIBC6 .M3EXPORTS libvideovbt.so.5 libvideovbt.a libvideovbt.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/videovbt/src/POSIX AudioVBT.m3 VideoVBT.m3 VideoVBTRep.i3 ../src => /usr/local/cm3/pkg/videovbt/src AudioVBT.i3 VideoVBT.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsvbtpixmaps/LINUXLIBC6 .M3EXPORTS libm3formsvbtpixmaps.so.5 libm3formsvbtpixmaps.a libm3formsvbtpixmaps.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/formsvbtpixmaps/LINUXLIBC6 FormsVBTPixmapsBundle.i3 FormsVBTPixmapsBundle.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsvbt/LINUXLIBC6 .M3EXPORTS libm3formsvbt.so.5 libm3formsvbt.a libm3formsvbt.m3x .M3WEB ../src => /usr/local/cm3/pkg/formsvbt/src StubImages.i3 StubImageRd.i3 StubImageRd.m3 StubImageVBT.i3 StubImageVBT.m3 FVTypes.i3 FormsVBT.i3 FormsVBT.m3 FVRuntime.m3 FVRuntime.i3 Manpage.i3 Manpage.m3 Macro.i3 Macro.m3 RefListUtils.i3 RefListUtils.m3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/formsview/LINUXLIBC6 .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/formsview/src formsview.m3 . => /usr/local/cm3/pkg/formsview/LINUXLIBC6 formsview --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/man/man1 formsedit.1 . => /usr/local/cm3/pkg/formsedit/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/formsedit/LINUXLIBC6 formseditBundle.i3 formseditBundle.m3 ../src => /usr/local/cm3/pkg/formsedit/src FormsEditVBT.i3 FormsEditVBT.m3 FormsEdit.m3 . => /usr/local/cm3/bin formsedit --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/opengl/LINUXLIBC6 .M3EXPORTS libopengl.so.5 libopengl.a libopengl.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/opengl/src/POSIX GL.i3 GLX.i3 GLu.i3 --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/webvbt/LINUXLIBC6 .M3EXPORTS libwebvbt.so.5 libwebvbt.a libwebvbt.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/webvbt/LINUXLIBC6 ResourceBundle.i3 ResourceBundle.m3 CITextElementTbl.i3 CITextElementTbl.m3 TextPortButtonSeq.m3 TextPortButtonSeq.i3 TextPortButtonSeqRep.i3 ../src => /usr/local/cm3/pkg/webvbt/src CIText.m3 CIText.i3 Element.i3 Lexer.i3 Lexer.m3 HTML.i3 HTML.m3 HTMLParser.m3 HTMLVBT.i3 HTMLVBT.m3 HTMLVBTG.m3 HTMLVBTG.i3 HTMLVBTGRep.i3 Images.m3 Images.i3 ImageUtils.i3 ImageUtils.m3 Oblet.i3 SimpleWeb.m3 SimpleWeb.i3 URLCache.i3 URLCache.m3 WebVBT.i3 WebVBT.m3 HTMLVBTText.i3 HTMLVBTText.m3 TextPortButton.i3 TextPortButton.m3 TextPortWithButtons.i3 TextPortWithButtons.m3 ../src/oblet => /usr/local/cm3/pkg/webvbt/src/oblet Oblet.m3 ObLibWeb.m3 ObLibWeb.i3 --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. hendrik at notlookedfor:~/cm3/collection-gui$ From jay.krell at cornell.edu Thu Jul 16 20:41:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:41:52 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: Yes. These are subtle but true points. os = cygwin or mingwin or interix or nt but mingwin is really nt, this is clarified below ostype = win32 or posix but this maps directly from os so isn't a multiplicative factor fork = fast or slow or none also maps from os/runtime backend = gcc or integrated gcc backend BITSIZE(LONGINT)==64 integrated backend BITSIZE(LONGINT)==32 I386_CYGWIN (NT386GNU) Posix, slow fork gcc backend, BITSIZE(LONGINT)==64 I386_MINGWIN (NT386MINGNU) Win32, probably no fork (though in reality there some hybrid aspects, intended only for the use of the compiler/linker/etc., intended not to be injected into stuff you build) gcc backend, BITSIZE(LONGINT)==64 I386_INTERIX Posix, fast fork uses gcc backend, BITSIZE(LONGINT)==64 I386_NT (NT386) Win32, no fork integrated backend, BITSIZE(LONGINT)==32 Cygwin hangs in one of the test cases. Mingw had some major problem last I checked like crashing in all gui apps. More combinations than this make sense. You could use the integrated backend with Cygwin or Interix for example. Mingwin, you know, is meant to be NT386 with the gcc backend. Mingwin is not an OS or runtime. Three runtimes: Cygwin, Interix, NT two backends: integrated, gcc therefore 6 combinations of which 4 are named above Consider that integrated backend could be adapted for I386_LINUX, I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... - Jay From: hosking at cs.purdue.edu To: wagner at elegosoft.com Date: Thu, 16 Jul 2009 10:39:03 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non-optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: Quoting "Rodney M. Bates" : A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 20:52:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:52:25 +0000 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: ps: Interix in fact, outside of Modula-3, can use gcc or Visual C++. They have a cc wrapper that translates the command line and calls cl.exe. Not sure if both linkers are available -- you know, because Interix seems to have substantial support for stuff Visual C++ link.exe does not have -- runpath, $origin. As well, Cygwin/mingw/Visual C++ all use the same object file format and to a significant extent can link each other's output. So you can use Visual C++ with Cygwin, gcc without a cygwin dependency. They have/had a gcc -mnocygwin switch, though there is tension between "biarch" vs. "just separate targets". So, actually, in cm3, these are all the same "target", "NT386", just different config files. This was an experiment and I'm still feeling mixed about the results. They way it is constructed leaves it generally pretty easy to construct the combinations that aren't named. You don't have to change cm3 at all, nor I think any m3makefile, just the config file. Well, in the m3makefiles, in m3core, there is deciding on using pthreads or NT threads, since you can use NT threads with Posix cygwin. You know, look at how SOLgnu and SOLsun are implemented -- they are all identical except for the config files. Similar situation but in this case they were broken out into separate targets, and all the target-specific code is /identical/. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elegosoft.com Date: Thu, 16 Jul 2009 18:41:52 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Yes. These are subtle but true points. os = cygwin or mingwin or interix or nt but mingwin is really nt, this is clarified below ostype = win32 or posix but this maps directly from os so isn't a multiplicative factor fork = fast or slow or none also maps from os/runtime backend = gcc or integrated gcc backend BITSIZE(LONGINT)==64 integrated backend BITSIZE(LONGINT)==32 I386_CYGWIN (NT386GNU) Posix, slow fork gcc backend, BITSIZE(LONGINT)==64 I386_MINGWIN (NT386MINGNU) Win32, probably no fork (though in reality there some hybrid aspects, intended only for the use of the compiler/linker/etc., intended not to be injected into stuff you build) gcc backend, BITSIZE(LONGINT)==64 I386_INTERIX Posix, fast fork uses gcc backend, BITSIZE(LONGINT)==64 I386_NT (NT386) Win32, no fork integrated backend, BITSIZE(LONGINT)==32 Cygwin hangs in one of the test cases. Mingw had some major problem last I checked like crashing in all gui apps. More combinations than this make sense. You could use the integrated backend with Cygwin or Interix for example. Mingwin, you know, is meant to be NT386 with the gcc backend. Mingwin is not an OS or runtime. Three runtimes: Cygwin, Interix, NT two backends: integrated, gcc therefore 6 combinations of which 4 are named above Consider that integrated backend could be adapted for I386_LINUX, I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... - Jay From: hosking at cs.purdue.edu To: wagner at elegosoft.com Date: Thu, 16 Jul 2009 10:39:03 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Release notes comments Are there any Windows targets using the gcc-based backend? If so then they will have BITSIZE(LONGINT)=64 too. It is just the integrated non-optimizing x86 back-end that currently defines BITSIZE(LONGINT)=32. On 16 Jul 2009, at 02:24, Olaf Wagner wrote: Quoting "Rodney M. Bates" : A couple of comments on the release notes for 5.8.2:
  • System pthread threading is now the default on all platforms. The original (fast) M3 user level thread code is still there and can be used if necessary (on most platforms). On many systems, this allows M3 applications to scale over all available hardware processors.
  • This sounds like it is the original user level threads that allow scaling over multiple processors, which I believe is backwards. I suggest swapping the second and third sentences be for clarity.
  • New data type LONGINT (64 bit integer) on all target platforms except Windows (still in the queue).
  • As I understand it, LONGINT is in Windows too, it just isn't 64 bits yet. Thanks Rodney, that was fast. After browsing the change logs for several hours, I just checked in that draft last night before falling asleep. I'd like everybody to have a look at them and correct, extend or add topics they'd like to change or see. Probably I've missed at least some. Order should also be considered. You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html now if you don't want to read them in your CVS workspace. Let me know what you think and feel free to improve the checked-in source, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 20:54:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 18:54:59 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword Message-ID: We have some redundancies that are causing me some grief. We have two units called M3ID. They have no overlap, and could be merged into one. "No overlap" doesn't mean they are completely unrelated, but sort of. More bothersome is that m3-sys\m3scanner and m3-tools\m3scan have near duplicate code, in particular the list of tokens and the Classify function. In particular, where people were using libm3\M3Config, there are problems using instead m3quake\MxConfig, because this can bring together the two M3IDs. I was going to replace all uses of M3Config with MxConfig. However to avoid the duplicate M3ID units, I think I'll keep M3Config and MxConfig more like duplicates of each other at least for now, to avoid bringing m3quake into places that have the other M3ID. M3Config is in libm3 and MxConfig is in m3quake. m3quake imports m3middle, which has M3ID. Therefore, if you use M3Config and have your own M3ID, you can't switch to MxConfig without renaming one of the M3IDs. This does occur in m3-tools. C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(25):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): TK = C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(360): END Classify; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.i3(12):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.m3(17):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T = - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 21:08:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 19:08:23 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword In-Reply-To: References: Message-ID: I might be able to win just by making m3scan/m3id.i3 not public, changing Module to module in the m3makefile or such. Or renaming it, same thing really. The unit name only occurs twice. I have to verify nobody uses it outside of m3scan though. Keeping MxConfig/M3Config duplicates isn't great, because I have MxConfig importing M3Config's constants, and then M3Config would want to have a Get function that called into MxConfig -- circularity..though the constants are generated and that could be copied instead...not a lot of duplication here in any case but I'll see... - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Thu, 16 Jul 2009 18:54:59 +0000 Subject: [M3devel] duplicated code and unit names -- M3ID, M3Keyword We have some redundancies that are causing me some grief. We have two units called M3ID. They have no overlap, and could be merged into one. "No overlap" doesn't mean they are completely unrelated, but sort of. More bothersome is that m3-sys\m3scanner and m3-tools\m3scan have near duplicate code, in particular the list of tokens and the Classify function. In particular, where people were using libm3\M3Config, there are problems using instead m3quake\MxConfig, because this can bring together the two M3IDs. I was going to replace all uses of M3Config with MxConfig. However to avoid the duplicate M3ID units, I think I'll keep M3Config and MxConfig more like duplicates of each other at least for now, to avoid bringing m3quake into places that have the other M3ID. M3Config is in libm3 and MxConfig is in m3quake. m3quake imports m3middle, which has M3ID. Therefore, if you use M3Config and have your own M3ID, you can't switch to MxConfig without renaming one of the M3IDs. This does occur in m3-tools. C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(25):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): TK = C:\dev2\cm3.2\m3-sys\m3scanner\src\M3Keyword.m3(360): END Classify; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.i3(12):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T; C:\dev2\cm3.2\m3-tools\m3scan\src\M3ID.m3(17):PROCEDURE Classify (READONLY x: ARRAY OF CHAR): M3Token.T = - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 16 21:47:13 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 16 Jul 2009 15:47:13 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <4A5E7496.7020308@cox.net> References: <4A5E7496.7020308@cox.net> Message-ID: <20090716194713.GA9452@topoi.pooq.com> On Wed, Jul 15, 2009 at 07:30:14PM -0500, Rodney M. Bates wrote: > A couple of comments on the release notes for 5.8.2: > >
  • System pthread threading is now the default on all > platforms. The original (fast) M3 user level thread code is > still there and can be used if necessary (on most platforms). On > many systems, this allows M3 applications to scale over all > available hardware processors.
  • > > This sounds like it is the original user level threads that allow > scaling over multiple processors, which I believe is backwards. > I suggest swapping the second and third sentences be for clarity. Actiually. the second sentence won't really work if it's moved to the start, since it seems to launch from the first one. Some rewording may be necessary as well as swapping. -- hendrik From jay.krell at cornell.edu Thu Jul 16 22:36:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 20:36:42 +0000 Subject: [M3devel] M3Config Message-ID: So..I was wondering..what were the original authors thinking? And there was that comment about the file containing the data upon install. Which seemed wrong to me. They were probably thinking of the way 3.6 was packaged and distributed -- everyone built the system from source, upon building m3build/m3ship from C and m3 from assembly. That isn't a bad model, but we probably want both. There are at least three times the paths can be computed/recorded: 1) when you build libm3 2) when you install libm3 #1 and #2 may or may not be close in time and have the same result. 3) by parsing cm3.cfg as needed #2 is more efficient than #3 and matches the old code, but #3 is how I left it, probably ok. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 16 23:01:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 16 Jul 2009 21:01:03 +0000 Subject: [M3devel] comment in Xmacro.m3 questioning correctness? Message-ID: C:\dev2\cm3.2\m3-ui\motif\src\Xmacro.m3(24): (* does this work on big-endian machines?? *) (*-----------------*) PROCEDURE CharVal(value:CHAR):Xt.ArgVal= BEGIN RETURN LOOPHOLE (ORD (value), Xt.ArgVal); (* does this work on big-endian machines?? *) END CharVal; The code is ok? Otherwise I can write it in portable C.. But I suspect it is ok and we can just strike the comment. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 09:40:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 07:40:07 +0000 Subject: [M3devel] suggest removing version numbers from library names Message-ID: versioning dynamic libraries/shared objects We do, like Darwin: libfoo.5.dylib symlink libfoo.5.2.dylib symlink libfoo.dylib actual file others: libfoo.so.5 symlink libfoo.so as are the conventions. (HP-UX I think just .sa instead of .so.) (NT: Just foo.dll.) I understand the point of this. I may be heretical and lazy, but I am not (entirely) ignorant. :) I suggest that maybe compatibility ("binary" *and* behavioral) and managing version numbers is too difficult, not worth it, that instead programs carry their dependencies with them, and that we just have: libfoo.dylib libfoo.so I further suggest, though it is independent, that we move the lib directory contents into bin. That makes "movement" or "relocation" just slightly easier. I further suggest that most people only consider "binary" compatibility, the parameter order and types of functions, the layout of structs, which is already maybe too difficult, and once one realizes that compatibility includes behavior, the problem is even much larger. I acknowledge that if everyone took this approach, the result would not be great. I assert that carrying dependencies with you eliminates much of the point of dynamic linking, but not all -- you still share among the contents of the same bin directory, code presumably all built around the same time and/or against the same interfaces. If all of the above is rejected, I assert at least that we should have the major.minor version number in the above names derive directly from the checked in version file, that they become 5.8 for this release on Darwin. Oh, hm. We actually aren't following the conventions. I should check if this is an accidental regression. On Birch I see a mix, of no version, three part version, two part version, though three part extension seems most common. Sometimes versions occur in inconsistent places. /usr/lib/libdbus-1.so.3@ /usr/lib/libdbus-1.so.3.2.0 /usr/lib/libdrvproxy.so@ /usr/lib/libdrvproxy.so.2@ /usr/lib/libdrvproxy.so.2.1.15 /usr/lib/libdb-4.2.so /usr/lib/libdb-4.3.so /usr/lib/libdb-4.4.so /usr/lib/libc.a /usr/lib/libc.so /usr/lib/libform.a /usr/lib/libform.so@ /usr/lib/libform.so.5@ /usr/lib/libform.so.5.5 /usr/lib/libcurl.so.3@ /usr/lib/libcurl.so.3.0.0 /usr/lib/libXt.a /usr/lib/libXt.so.6@ /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 /usr/lib/libpython2.4.so@ /usr/lib/libpython2.4.so.1.0 /usr/lib/libpython2.4.so.1@ /usr/lib/libfreetype.a /usr/lib/libfreetype.la (Yes, I've heard of libtool.) /usr/lib/libfreetype.so@ /usr/lib/libfreetype.so.6@ /usr/lib/libfreetype.so.6.3.10 % more /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-x86- 64.so.2 ) ) % ls /lib/libc* /lib/libc.so.6@ etc. so I amend the previous to 5.8.1 on Linux also, and check what other systems do. But really, the first suggestion -- no versions. I wouldn't mind dropping the "lib" prefix but I think that breaks the static vs. dynamic probing that occurs on Darwin and maybe others. Though we do our own thing on Windows with Modula-3 where have foo.lib dynamic foo.lib.sa standalone and the Quake code handles the probing. It should be further noted that various systems including Linux, Solaris, and I believe some of the BSDs have yet another versioning mechanism in use, where, roughly speaking, functions get version names appended to them, but that is not visible at the source level, not even with #defines or #pragmas or inlines, though there is some of that too. Therefore, they can and do rev file names much less frequently than one might expect if one only knew about the use of version numbers in file names. I note this as sort of a counterpoint to the assertion that we should follow the conventions, because, arguably, we aren't fully following them, and probably never will. It'd take inventing new mechanisms to shadow the C mechanisms, and it wouldn't be portable. Realize, $ORIGIN is important to this. NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous. Probably drop support for 4.0. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:28:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:28:58 +0000 Subject: [M3devel] cm3ide crash Message-ID: I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:46:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:46:27 +0000 Subject: [M3devel] FW: cm3ide crash Message-ID: [truncated] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3ide crash Date: Fri, 17 Jul 2009 12:28:58 +0000 I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:46:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:46:02 +0000 Subject: [M3devel] gdb on Darwin Message-ID: Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. AMD64 gives and error that BFD is not supported. x86 skips the critical gdb directory because it isn't supported. If we want this to work, we should probably the importing Apple's fork? Like I did for ARM_DARWIN m3cc? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:47:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:47:26 +0000 Subject: [M3devel] cm3ide crash Message-ID: [truncated again] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3ide crash Date: Fri, 17 Jul 2009 12:28:58 +0000 I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 17 14:50:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 12:50:08 +0000 Subject: [M3devel] cm3ide crash Message-ID: [and again..I'll trim the part that wasn't truncated..] ---- For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 15:48:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 09:48:35 -0400 Subject: [M3devel] cm3ide crash In-Reply-To: References: Message-ID: <60F32660-0DF9-480E-959F-712A51ED0278@cs.purdue.edu> Looks like a null pointer. Sent from my iPhone On Jul 17, 2009, at 8:47 AM, Jay K wrote: > > [truncated again] > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: cm3ide crash > Date: Fri, 17 Jul 2009 12:28:58 +0000 > > > > > > > > > I used cm3ide for a few minutes. > I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when > compiling) it is constructed in a roundabout fashion by running the > code. > See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config > file I usually use. > > Clicking on the examples link: > > (gdb) r > Starting program: /cm3/bin/cm3ide > warning: posix_spawn failed, trying execvp, error: 86 > CAUTION: PKG_USE not defined in cm3.cfg, constructed it from > cm3.cfg path as: /cm3/pkg > CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from > package root as: /cm3/doc > NOTICE: Unable to locate 'examples' folder. > Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 > calling start_browser(http://localhost:3800/) > /Applications/Firefox.app/Contents/MacOS/firefox http://localhost: > 3800/ > starting TCP service > Scanning Packages: Jul 17 05:15... > ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? > scan done: Jul 17 06:27 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > [Switching to process 23997 thread 0x2703] > 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ > Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ > text/Text.m3:16 > #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) > at ../src/os/POSIX/PathnamePosix.m3:65 > #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/ > os/POSIX/FSPosix.m3:243 > #3 0x0000000100042713 in Roots__ScanExamples > (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 > #4 0x0000000100042338 in Roots__ExamplesRootPage > (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, > M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 > #5 0x000000010005abc0 in WebServer__ProcessRequest > (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/ > WebServer.m3:325 > #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) > at ../src/server/TCPServer.m3:116 > #7 0x000000010011b52a in ThreadPThread__RunThread > (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ > ThreadPThread.m3:547 > #8 0x000000010011b1b6 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ > ThreadPThread.m3:523 > #9 0x00007fff82a66deb in _pthread_start () > #10 0x00007fff82a66cad in thread_start () > > There are other problems. > It prompted me for my browser. > > On a Mac, it could offer choices like: > > jaypro:cm3ide jay$ find /Applications | grep -i fox$ > /Applications/Firefox.app/Contents/MacOS/firefox > > jaypro:cm3ide jay$ find /Applications | grep -i fari$ > /Applications/Safari.app/Contents/MacOS/Safari > > if they exist. > Of course I should try Opera and whatever else and report their paths. > > I had to close any existing Firefox, else I got an error that only > one Firefox can run at a time. > The error came from Firefox, not cm3ide. > > For the prompt for editor, I grant there may be too many options to > offer From hosking at cs.purdue.edu Fri Jul 17 15:50:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 09:50:36 -0400 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: Let's avoid pandering to Apple's forks. Better to upgrade to FSF sources that (eventually) should catch up. Sent from my iPhone On Jul 17, 2009, at 8:46 AM, Jay K wrote: > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. > AMD64 gives and error that BFD is not supported. > x86 skips the critical gdb directory because it isn't supported. > > If we want this to work, we should probably the importing Apple's > fork? > Like I did for ARM_DARWIN m3cc? > > - Jay > > > From wagner at elegosoft.com Fri Jul 17 18:51:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 18:51:25 +0200 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> Message-ID: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Well, it would be great if somebody could (a) provide a short update for the release notes regarding LONGINT and (b) put this into two or three paragraphs (perhaps in their own document) that ordinary users may understand and want to know Olaf Quoting Jay K : > > ps: Interix in fact, outside of Modula-3, can use gcc or Visual C++. > > They have a cc wrapper that translates the command line and calls cl.exe. > > Not sure if both linkers are available -- you know, because Interix > seems to have > > substantial support for stuff Visual C++ link.exe does not have -- > runpath, $origin. > > > > > > As well, Cygwin/mingw/Visual C++ all use the same object file format and > > to a significant extent can link each other's output. > > So you can use Visual C++ with Cygwin, gcc without a cygwin dependency. > > They have/had a gcc -mnocygwin switch, though there is tension > > between "biarch" vs. "just separate targets". > > > > > > So, actually, in cm3, these are all the same "target", "NT386", just > different config files. > > This was an experiment and I'm still feeling mixed about the results. > > > > They way it is constructed leaves it generally pretty easy to > construct the combinations > > that aren't named. You don't have to change cm3 at all, nor I think > any m3makefile, > > just the config file. Well, in the m3makefiles, in m3core, there is > deciding on > > using pthreads or NT threads, since you can use NT threads with Posix cygwin. > > > > > > You know, look at how SOLgnu and SOLsun are implemented -- they are > all identical > > except for the config files. Similar situation but in this case they > were broken > > out into separate targets, and all the target-specific code is /identical/. > > > > > > - Jay > > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Thu, 16 Jul 2009 18:41:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release notes comments > > > > Yes. These are subtle but true points. > > > os = cygwin or mingwin or interix or nt > but mingwin is really nt, this is clarified below > ostype = win32 or posix > but this maps directly from os so isn't a multiplicative factor > fork = fast or slow or none > also maps from os/runtime > backend = gcc or integrated > gcc backend BITSIZE(LONGINT)==64 > integrated backend BITSIZE(LONGINT)==32 > > > I386_CYGWIN (NT386GNU) > Posix, slow fork > gcc backend, BITSIZE(LONGINT)==64 > > I386_MINGWIN (NT386MINGNU) > Win32, probably no fork (though in reality there some hybrid > aspects, intended > only for the use of the compiler/linker/etc., intended not to be > injected into stuff you build) > gcc backend, BITSIZE(LONGINT)==64 > > I386_INTERIX > Posix, fast fork > uses gcc backend, BITSIZE(LONGINT)==64 > > I386_NT (NT386) > Win32, no fork > integrated backend, BITSIZE(LONGINT)==32 > > Cygwin hangs in one of the test cases. > Mingw had some major problem last I checked like crashing in all gui apps. > > More combinations than this make sense. > You could use the integrated backend with Cygwin or Interix for example. > Mingwin, you know, is meant to be NT386 with the gcc backend. > Mingwin is not an OS or runtime. > > Three runtimes: Cygwin, Interix, NT > two backends: integrated, gcc > > therefore 6 combinations of which 4 are named above > > Consider that integrated backend could be adapted for I386_LINUX, > I386_SOLARIS, I386_FREEBSD ("FreeBSD4"), I386_OPENBSD, I386_NETBSD, > I386_PLAN9, I386_DRAGONFLYBSD, I386_DARWIN, etc... > > - Jay > > > > > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Thu, 16 Jul 2009 10:39:03 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release notes comments > > > > > > Are there any Windows targets using the gcc-based backend? If so > then they will have BITSIZE(LONGINT)=64 too. It is just the > integrated non-optimizing x86 back-end that currently defines > BITSIZE(LONGINT)=32. > > > On 16 Jul 2009, at 02:24, Olaf Wagner wrote: > > Quoting "Rodney M. Bates" : > > > A couple of comments on the release notes for 5.8.2:
  • System > > pthread threading is now the default on all > > platforms. The original (fast) M3 user level thread code is > > still there and can be used if necessary (on most platforms). On > > many systems, this allows M3 applications to scale over all > > available hardware processors.
  • > > > > This sounds like it is the original user level threads that allow > > scaling over multiple processors, which I believe is backwards. I > > suggest swapping the second and third sentences be for clarity. > >
  • New data type LONGINT (64 bit integer) on all target > > platforms except Windows (still in the queue).
  • > > > > As I understand it, LONGINT is in Windows too, it just isn't 64 > > bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:02:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:02:59 +0200 Subject: [M3devel] M3Config In-Reply-To: References: Message-ID: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> Quoting Jay K : > So..I was wondering..what were the original authors thinking? > > And there was that comment about the file containing the data upon install. > > Which seemed wrong to me. > > They were probably thinking of the way 3.6 was packaged and > distributed -- everyone built the system from source, upon building > m3build/m3ship from C and m3 from assembly. > > That isn't a bad model, but we probably want both. > > There are at least three times the paths can be computed/recorded: > > 1) when you build libm3 > 2) when you install libm3 > #1 and #2 may or may not be close in time and have the same result. > 3) by parsing cm3.cfg as needed > > #2 is more efficient than #3 and matches the old code, but #3 is how > I left it, probably ok. I'd prefer that, too. I take it that you've changed the code correspondingly and we should move the RC2 tag? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:07:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:07:10 +0200 Subject: [M3devel] FW: cm3ide crash In-Reply-To: References: Message-ID: <20090717190710.deb46kibk4k8w40w@mail.elegosoft.com> Can anybody fix that crash? It's probably just a missing text or other NIL pointer (missing examples)... Olaf Quoting Jay K : > I used cm3ide for a few minutes. > I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when > compiling) it is constructed in a roundabout fashion by running the > code. > See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config > file I usually use. > > Clicking on the examples link: > > (gdb) r > Starting program: /cm3/bin/cm3ide > warning: posix_spawn failed, trying execvp, error: 86 > CAUTION: PKG_USE not defined in cm3.cfg, constructed it from > cm3.cfg path as: /cm3/pkg > CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from > package root as: /cm3/doc > NOTICE: Unable to locate 'examples' folder. > Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 > calling start_browser(http://localhost:3800/) > /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ > starting TCP service > Scanning Packages: Jul 17 05:15... > ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? > scan done: Jul 17 06:27 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > [Switching to process 23997 thread 0x2703] > 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at > ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at > ../src/text/Text.m3:16 > #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at > ../src/os/POSIX/PathnamePosix.m3:65 > #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at > ../src/os/POSIX/FSPosix.m3:243 > #3 0x0000000100042713 in Roots__ScanExamples > (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 > #4 0x0000000100042338 in Roots__ExamplesRootPage > (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, > M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 > #5 0x000000010005abc0 in WebServer__ProcessRequest > (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at > ../src/misc/WebServer.m3:325 > #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at > ../src/server/TCPServer.m3:116 > #7 0x000000010011b52a in ThreadPThread__RunThread > (M3_CgoaiZ_me=0x100d02270) at > ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x000000010011b1b6 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x100d02270) at > ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x00007fff82a66deb in _pthread_start () > #10 0x00007fff82a66cad in thread_start () -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jul 17 19:14:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Jul 2009 19:14:06 +0200 Subject: [M3devel] suggest removing version numbers from library names In-Reply-To: References: Message-ID: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> I think ELF dynamic linkers actually understand just one version number (but may be wrong there). If this is correct, we should probably limit our numbers to that, too. The interesting question is, who is going to increase the number of a dynamic library based on an incompatible change? And can that even be done, or are all the numbers fixed in the config files? I wouldn't be against removing unused complexity. As for moving all libs to bin, I'd postpone that after the release and a perhaps controverse discussion. Olaf Quoting Jay K : > > versioning dynamic libraries/shared objects > > > We do, like > > > Darwin: > libfoo.5.dylib symlink > libfoo.5.2.dylib symlink > libfoo.dylib actual file > > > > others: > libfoo.so.5 symlink > libfoo.so > > > > > > as are the conventions. > > > > (HP-UX I think just .sa instead of .so.) > > (NT: Just foo.dll.) > > > > > I understand the point of this. > I may be heretical and lazy, but I am not (entirely) ignorant. :) > > > > > I suggest that maybe compatibility ("binary" *and* behavioral) and > managing version numbers > is too difficult, not worth it, that instead programs carry their > dependencies with > them, and that we just have: > > > > > libfoo.dylib > libfoo.so > > > > > I further suggest, though it is independent, > that we move the lib directory contents into bin. > That makes "movement" or "relocation" just slightly easier. > > > > > > I further suggest that most people only consider "binary" compatibility, > > the parameter order and types of functions, the layout of structs, > > which is already maybe too difficult, and once one realizes that > compatibility > > includes behavior, the problem is even much larger. > > > > > I acknowledge that if everyone took this approach, the result would > not be great. > > > > > I assert that carrying dependencies with you eliminates much of the point > of dynamic linking, but not all -- you still share among the contents of > the same bin directory, code presumably all built around the same time > and/or against the same interfaces. > > > > > > If all of the above is rejected, I assert at least that we should > have the major.minor version number in the above names derive > directly from the checked in version file, that they become 5.8 for this > release on Darwin. > > > > > Oh, hm. We actually aren't following the conventions. > I should check if this is an accidental regression. > > > > > On Birch I see a mix, of no version, three part version, two part version, > though three part extension seems most common. Sometimes versions > occur in inconsistent > places. > > > > > /usr/lib/libdbus-1.so.3@ > /usr/lib/libdbus-1.so.3.2.0 > > > > > /usr/lib/libdrvproxy.so@ > /usr/lib/libdrvproxy.so.2@ > /usr/lib/libdrvproxy.so.2.1.15 > > > /usr/lib/libdb-4.2.so > /usr/lib/libdb-4.3.so > /usr/lib/libdb-4.4.so > > /usr/lib/libc.a /usr/lib/libc.so > > > > > /usr/lib/libform.a > /usr/lib/libform.so@ > /usr/lib/libform.so.5@ > /usr/lib/libform.so.5.5 > > > > > /usr/lib/libcurl.so.3@ > /usr/lib/libcurl.so.3.0.0 > > > > > /usr/lib/libXt.a /usr/lib/libXt.so.6@ > /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 > > > > > /usr/lib/libpython2.4.so@ > > /usr/lib/libpython2.4.so.1.0 > /usr/lib/libpython2.4.so.1@ > > > > > /usr/lib/libfreetype.a > /usr/lib/libfreetype.la (Yes, I've heard of libtool.) > /usr/lib/libfreetype.so@ > /usr/lib/libfreetype.so.6@ > /usr/lib/libfreetype.so.6.3.10 > > > > % more /usr/lib/libc.so > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf64-x86-64) > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > /lib/ld-linux-x86- > 64.so.2 ) ) > > > > % ls /lib/libc* > /lib/libc.so.6@ > > > etc. > > > so I amend the previous to 5.8.1 on Linux also, and check what other > systems do. > > > > > But really, the first suggestion -- no versions. > > > > > I wouldn't mind dropping the "lib" prefix but I think that breaks the > static vs. dynamic probing that occurs on Darwin and maybe others. > Though we do our own thing on Windows with Modula-3 where have > foo.lib dynamic > foo.lib.sa standalone > > > > > and the Quake code handles the probing. > > > > > It should be further noted that various systems including Linux, > Solaris, and I believe > some of the BSDs have yet another versioning mechanism in use, > where, roughly speaking, > functions get version names appended to them, but that is not > visible at the source level, > not even with #defines or #pragmas or inlines, though there is some > of that too. > > > > > Therefore, they can and do rev file names much less frequently than > one might expect > if one only knew about the use of version numbers in file names. > > > > > I note this as sort of a counterpoint to the assertion that we > should follow the conventions, > because, arguably, we aren't fully following them, and probably never will. > It'd take inventing new mechanisms to shadow the C mechanisms, and > it wouldn't be portable. > > > > > > Realize, $ORIGIN is important to this. > > NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous. > > Probably drop support for 4.0. > > > > > > - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Fri Jul 17 19:26:30 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 13:26:30 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Message-ID: <4A607BEF.1E75.00D7.1@scires.com> Olaf: I have read thru the "Release Notes CM3 5.8.2" page and the "CM3 Release Candidate Index" page. Great job putting this together! Here are some comments for your consideration: 1. The section on "Package", particularly the first paragraph, I think is a bit confusing. The CM3IDE documentation includes a lot of information on packages, so perhaps the missing link in this section should reference that documentation. To me, a package is a set of sources that together represent one compilation unit for the purpose of building a library, program, or other assemblage of information (e.g., documentation). Each package resides in a directory (folder), with sources and generated files in subdirectories (sub folders) of the package's folder. In the top-level CM3 source tree, packages are grouped into categories, with each category represented by a subfolder rooted in that top-level, and the packages comprising each category rooted in the category's folder. 2. I presume that we do intend to make NT386 available for this release, even though it says "Not Available Yet". 3. I find the "-bin-min-" and "-bin-core-" terminology a bit confusing. To me, the "core" of something is the "heart" or "minimal" part of it. Would it make more sense to rename "-bin-core-" to "-bin-std-"? Indeed the explanation given for "core" says in one place that it represents a "standard" installation. In another place it is called "package pool". Also, "min" in one place is called the "central installation hierarchy". Suggest we be consistent. To me it makes more sense to have "min" represent the "minimal installation" and "std" the "standard installation" and "all" represents "everything." 4. I don't understand the "-bin-ws-" concept of "precompiled user workspace" and how it would be useful. Please elaborate. 5. All of the instructions seem to apply for UNIX-like environments. We need to augment these to include how to do it on non-Unix environments, such as Windows. For the scripts, like "install.sh", do we intend to provide Windows command/batch files, e.g. "install.cmd" or "install.bat"? 6. When we finally settle on a release name, need to update the names in these instructions, e.g., replace "d5.8.1-RC1" under "Installation Procedure", and "RC1" in other places. 7. "Installation Procedure" step #5, change "shop" to "ship". 8. "In case of problems" step #4, last line, change "volunteers" to "volunteer" and change "his" to "his/her". Hope some of this helps. Thanks for all your work on this!!! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Fri Jul 17 19:26:40 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 17 Jul 2009 10:26:40 -0700 (PDT) Subject: [M3devel] Request web page updates Message-ID: <670632.92136.qm@web56801.mail.re3.yahoo.com> Hi Olaf, Lets try to get the web site into "ship shape", getting ready for visitors coming to check us out, after reading about the latest release. Can your servers handle the Slashdot effect? Anyways, here are a few suggestions. 1 - Downloads: Could you put a link to the tarball for the 5.8.x release canididate (RC2) onto the web server, more specifically on http://opencm3.net/download.html Once, the final version if 5.8.x is released, remove the link to the RCx tarball, in favor of a permanent link to that final release, just like the 5.4 release. 2 - News: (a) It would also be very nice if the "home" or start page brings up "news" items. I always forget to look at the current news page. Actually I just discovered that it is there. (b) You should add a news item promoting the use of the release candidate, to help expose any regressions before the final release. (c) The major changes to the compiler should be listed somewhere, since the last release shown on the download page. Right now the last release indicated is 5.4. There are some snapshots of 5.5, but not final release of 5.5. 3 - About-CM3: The "About CM3" page, should have a section listing all the changes / enhancements to the language that it accepts vice that described in the language reference from Nelson's SPWM3. For example, WIDECHAR, LONGINT are two new primitive types. Also list all the pragmas recognized by the compiler as that is a compiler unique issue. http://opencm3.net/about-cm3.html It should also list all the architectures that are supported by the compiler. These should always reflect those of the latest "release" version of the compiler. 4 - FAQ: Is there a way to get a single page for the FAQ for the FAQ, one that is easy to print? I haven't had the time to look it over yet, so in time, I will be asking "questions", that we may want to add as FAQ items. 5 - ROADMAP: We should have a page on which we record suggestions for changes to the compiler, libraries, and build system. This should capture the long term goals which require thinking and concurrence among the community. Simple things such as bug fixes would not be listed here. These requested changes (and amendments to them), could then be prioritized, and tracked. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Fri Jul 17 19:35:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:35:13 -0400 Subject: [M3devel] M3Config In-Reply-To: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> References: <20090717190259.itgaja18g4ksk088@mail.elegosoft.com> Message-ID: On 17 Jul 2009, at 13:02, Olaf Wagner wrote: > Quoting Jay K : > >> So..I was wondering..what were the original authors thinking? This may be lost in the mists of time. Recall that there were originally two implementations of Modula-3: Olivetti's and DEC's. Remnants of both are in CM3. Perhaps this is an artefact of the merge? >> >> And there was that comment about the file containing the data upon >> install From rcoleburn at scires.com Fri Jul 17 19:41:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 13:41:57 -0400 Subject: [M3devel] cm3ide crash In-Reply-To: References: Message-ID: <4A607F8E.1E75.00D7.1@scires.com> Jay: I've not seen the whole of your message yet; I've received multiple truncated copies. Recall that CM3IDE is the open-source version of "Reactor". Reactor was tightly woven into the CM3 4.1 commercial release. During the install process, cm3install actually adjusted the cm3.cfg file to reflect the installation location, location of your preferred browser, preferred editor, etc. I know you don't use cm3install, and you've made changes to the cm3.cfg files, so if some of this stuff isn't going to be there going forward, I need to make adjustments to CM3IDE. When CM3IDE runs, if it doesn't find these variables in the cm3.cfg file, it tries to locate the appropriate stuff, hence the "CAUTION" messages you saw on stdout. In some cases, it asks the same type question that cm3install would have asked about the editor et al, then saves this information in its configuration file located in the user's home folder. Once the info is saved, it won't prompt you for it again. The error you are getting about the examples folder is probably due to you not copying this folder into your CM3 tree. There are README files explaining all this. If you don't have the examples folder, CM3IDE will still function, except you won't be able to build any of the examples. The examples are all pretty neat IMO, and CM3IDE actually builds them in your private workspace, so you can edit the sources and play around with them without affecting anyone else who wants to try out the examples. Each user gets a fresh copy from the examples folder. Not sure about the crash you are reporting, whether it is due to some problem with your cm3.cfg or your installation or just a bug. I don't experience this crash on Windows, but I have not rebuilt CM3IDE against the latest source tree yet. Perhaps a recent change to the source tree has impacted CM3IDE. I'm supposed to go rafting and camping this weekend with my son's Boy Scout troop, so I don't think I'll have much time to work on this problem. If I get back early, I'll try to look at the problem Sunday evening. Regards, Randy Coleburn >>> Jay K 7/17/2009 8:28 AM >>> I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 19:43:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:43:57 -0400 Subject: [M3devel] Lots of errors in latest Tinderbox on Solaris Message-ID: There seems to be something severely broken: Things like: unable to open "/homes/hosking/tmp/cm3/niagara/cm3/pkg/m3quake/ SOLgnu/.M3EXPORTS" for reading file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/ lib /opt/lib unable to open "/scratch/hosking/work/cm3-ws/ niagara-2009-07-17-10-30-05/cm3/m3-tools/cvsup/suplib/ SOLgnu/.M3EXPORTS" for reading ... Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 17 19:57:20 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Jul 2009 13:57:20 -0400 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: Message-ID: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> It seems worrisome that m3tohtml is failing. 34147 HTML package report in /var/folders/Q6/ Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report- I386_DARWIN-2009-07-17-06-27-10.html 34148 >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 / Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34149 === 2009-07-17 06:30:30 cm3 package status run done 34150 === 2009-07-17 06:30:30 build HTML package doc in / Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version 34151 34152 34153 *** 34154 NEXT *** runtime error: 34155 *** Segmentation violation - possible attempt to dereference NIL 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/ Text.m3 34157 *** 34158 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes 34160 8316 Abort trap | m3tohtml -dir html $pkgs 34161 >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/ hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34162 === 2009-07-17 06:30:30 m3tohtml run done -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 17 23:34:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Jul 2009 17:34:57 -0400 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> Message-ID: <4A60B629.1E75.00D7.1@scires.com> I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. Regards, Randy Coleburn >>> Tony Hosking 7/17/2009 1:57 PM >>> It seems worrisome that m3tohtml is failing.34147 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34147 ) HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html34148 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34148 ) >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-0634149 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34149 ) === 2009-07-17 06:30:30 cm3 package status run done34150 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34150 ) === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version34151 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34151 ) 34152 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34152 ) 34153 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34153 ) ***34154 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34154 ) NEXT ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#err51 ) *** runtime error:34155 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34155 ) *** Segmentation violation - possible attempt to dereference NIL34156 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34156 ) *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m334157 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34157 ) ***34158 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34158 ) 34159 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34159 ) regression-scripts/defs.sh: line 712: 8315 Broken pipe yes34160 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34160 ) 8316 Abort trap | m3tohtml -dir html $pkgs34161 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34161 ) >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-0634162 ( http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1247812239.5037#34162 ) === 2009-07-17 06:30:30 m3tohtml run done CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 18 00:56:23 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 17 Jul 2009 18:56:23 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> Message-ID: <20090717225623.GA12084@topoi.pooq.com> On Thu, Jul 16, 2009 at 08:24:22AM +0200, Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > > >A couple of comments on the release notes for 5.8.2:
  • System > >pthread threading is now the default on all > > platforms. The original (fast) M3 user level thread code is > > still there and can be used if necessary (on most platforms). On > > many systems, this allows M3 applications to scale over all > > available hardware processors.
  • > > > >This sounds like it is the original user level threads that allow > >scaling over multiple processors, which I believe is backwards. I > >suggest swapping the second and third sentences be for clarity. > >
  • New data type LONGINT (64 bit integer) on all target > > platforms except Windows (still in the queue).
  • > > > >As I understand it, LONGINT is in Windows too, it just isn't 64 > >bits yet. > > Thanks Rodney, that was fast. After browsing the change logs for several > hours, I just checked in that draft last night before falling asleep. > > I'd like everybody to have a look at them and correct, extend or add > topics they'd like to change or see. Probably I've missed at least some. > Order should also be considered. > > You can browse them at http://www.opencm3.net/releng/relnotes-5.8-RC2.html > now if you don't want to read them in your CVS workspace. > > Let me know what you think and feel free to improve the checked-in source, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Current information on Modula 3 is still hard to get, Googling 'Modula 3' still give a lot of links to obsolete information. Perhaps I could update the Wikipedia entry to point to http://www.opencm3.net/releng/ as the place to find information on current development? I know it's only there temporarily, but it's always possible to update it when it moves to its permanent place. Uh ... That is the proper place right now, isn't it? If you approve, I'll do it the next time I'm online long enough (which may not be for a few days; I'm travelling). Unless someone beats me to it, of course. (hint, hint) -- hendrik From jay.krell at cornell.edu Sat Jul 18 01:20:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:20:02 +0000 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: <4A60B629.1E75.00D7.1@scires.com> References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> <4A60B629.1E75.00D7.1@scires.com> Message-ID: Ok sorry I think I understand this all much better now and it should work now. Please let's see how the next runs go. - Jay Date: Fri, 17 Jul 2009 17:34:57 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. Regards, Randy Coleburn >>> Tony Hosking 7/17/2009 1:57 PM >>> It seems worrisome that m3tohtml is failing.34147 HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html 34148 >>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34149 === 2009-07-17 06:30:30 cm3 package status run done 34150 === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version 34151 34152 34153 *** 34154 NEXT *** runtime error: 34155 *** Segmentation violation - possible attempt to dereference NIL 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m3 34157 *** 34158 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes 34160 8316 Abort trap | m3tohtml -dir html $pkgs 34161 >>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 34162 === 2009-07-17 06:30:30 m3tohtml run done -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:27:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:27:42 +0000 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: Apple doesn't push up all its changes, I think because they think/know they wouldn't all be accepted. But granted, actually just supporting a target, should be acceptable. Problems may be more like language changes for Mac source compat, though I'd think with flags to turn them off/on, they'd be ok, but that's another point. The lag does seem severe here though. I guess wait for the gdb 7.0 release and then reevaluate? In the meantime, no m3gdb for I386_DARWIN, AMD64_DARWIN. I haven't tried PPC_DARWIN yet. I agree the forking is unfortunate. Even if it is temporary, it seems to go too long. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 17 Jul 2009 09:50:36 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gdb on Darwin > > Let's avoid pandering to Apple's forks. Better to upgrade to FSF > sources that (eventually) should catch up. > > Sent from my iPhone > > On Jul 17, 2009, at 8:46 AM, Jay K wrote: > > > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/AMD64. > > AMD64 gives and error that BFD is not supported. > > x86 skips the critical gdb directory because it isn't supported. > > > > If we want this to work, we should probably the importing Apple's > > fork? > > Like I did for ARM_DARWIN m3cc? > > > > - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:37:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:37:39 +0000 Subject: [M3devel] suggest removing version numbers from library names In-Reply-To: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> References: <20090717191406.2766z87m880s4ksw@mail.elegosoft.com> Message-ID: I think regarding this file name thing, the linker doesn't have to understand anything at all. Granted that it might. You know, just give an "install name", foo.123.3456, just a string, of arbitrary content, and then manage symlinks appropriately. I'm not sure the dynamic linker has any knowledge of their being numbers and ordering. I thought it was just management of symlinks. And then there is some "internal versioning" that goes on. I don't know if that is all in the static linker or some cooperating between the static linker and dynamic linker. The numbers are in the config files yes. But hey, only about two of them now. :) Unix.common and Darwin.common. That has been the case as long as I've been paying close attention. (Mind you, that's shorter than paying passing attention. :) ) (That is, I'd have to go look at 3.x and 4.x to know, I've just seen 5 and 5.2 forever). > The interesting question is, whois going to increase > the number of a dynamic library based onan incompatible change? And, what is an "incompatible change"? I'm not stupid, I know what an "obvious incompatible change" is, but there are many "subtle possibly incompatible changes", such as to suggest nearly any change is incompatible. Thus, why I suggest it is perhaps almost intractable and just give up, rely on $ORIGIN, and don't support much of a "range" of anything. I just watched Theo de Radt (OpenBSD) talk about release engineering. Some interesting relevant points: "release engineering is testing" I thought testing was an ongoing thing. This actually can vary. "X11 is a big mess" (ok, that's not relevant :) ) "OpenBSD aggressively bumps library version numbers" A passing comment that was hard to hear but I believe he said "We don't believe GNU [or what is ELF?] versioning works and don't use it". I /think/ he was reverring to the "internal versioning" but he didn't elaborate. Maybe I just want him to be referring to it so I can write it off without bothering to understand it. :) OpenBSD's basic fix to release engineering and inadequate testing is dogfooding. /Arguably/ we do that too. We at least build the system and run some tests every day. As to "intensive use" of daily builds, that's harder to see. - Jay > Date: Fri, 17 Jul 2009 19:14:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] suggest removing version numbers from library names > > I think ELF dynamic linkers actually understand just one version number > (but may be wrong there). If this is correct, we should probably > limit our numbers to that, too. The interesting question is, who > is going to increase the number of a dynamic library based on > an incompatible change? And can that even be done, or are all the > numbers fixed in the config files? > > I wouldn't be against removing unused complexity. > > As for moving all libs to bin, I'd postpone that after the release > and a perhaps controverse discussion. > > Olaf > > Quoting Jay K : > > > > > versioning dynamic libraries/shared objects > > > > > > We do, like > > > > > > Darwin: > > libfoo.5.dylib symlink > > libfoo.5.2.dylib symlink > > libfoo.dylib actual file > > > > > > > > others: > > libfoo.so.5 symlink > > libfoo.so > > > > > > > > > > > > as are the conventions. > > > > > > > > (HP-UX I think just .sa instead of .so.) > > > > (NT: Just foo.dll.) > > > > > > > > > > I understand the point of this. > > I may be heretical and lazy, but I am not (entirely) ignorant. :) > > > > > > > > > > I suggest that maybe compatibility ("binary" *and* behavioral) and > > managing version numbers > > is too difficult, not worth it, that instead programs carry their > > dependencies with > > them, and that we just have: > > > > > > > > > > libfoo.dylib > > libfoo.so > > > > > > > > > > I further suggest, though it is independent, > > that we move the lib directory contents into bin. > > That makes "movement" or "relocation" just slightly easier. > > > > > > > > > > > > I further suggest that most people only consider "binary" compatibility, > > > > the parameter order and types of functions, the layout of structs, > > > > which is already maybe too difficult, and once one realizes that > > compatibility > > > > includes behavior, the problem is even much larger. > > > > > > > > > > I acknowledge that if everyone took this approach, the result would > > not be great. > > > > > > > > > > I assert that carrying dependencies with you eliminates much of the point > > of dynamic linking, but not all -- you still share among the contents of > > the same bin directory, code presumably all built around the same time > > and/or against the same interfaces. > > > > > > > > > > > > If all of the above is rejected, I assert at least that we should > > have the major.minor version number in the above names derive > > directly from the checked in version file, that they become 5.8 for this > > release on Darwin. > > > > > > > > > > Oh, hm. We actually aren't following the conventions. > > I should check if this is an accidental regression. > > > > > > > > > > On Birch I see a mix, of no version, three part version, two part version, > > though three part extension seems most common. Sometimes versions > > occur in inconsistent > > places. > > > > > > > > > > /usr/lib/libdbus-1.so.3@ > > /usr/lib/libdbus-1.so.3.2.0 > > > > > > > > > > /usr/lib/libdrvproxy.so@ > > /usr/lib/libdrvproxy.so.2@ > > /usr/lib/libdrvproxy.so.2.1.15 > > > > > > /usr/lib/libdb-4.2.so > > /usr/lib/libdb-4.3.so > > /usr/lib/libdb-4.4.so > > > > /usr/lib/libc.a /usr/lib/libc.so > > > > > > > > > > /usr/lib/libform.a > > /usr/lib/libform.so@ > > /usr/lib/libform.so.5@ > > /usr/lib/libform.so.5.5 > > > > > > > > > > /usr/lib/libcurl.so.3@ > > /usr/lib/libcurl.so.3.0.0 > > > > > > > > > > /usr/lib/libXt.a /usr/lib/libXt.so.6@ > > /usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0 > > > > > > > > > > /usr/lib/libpython2.4.so@ > > > > /usr/lib/libpython2.4.so.1.0 > > /usr/lib/libpython2.4.so.1@ > > > > > > > > > > /usr/lib/libfreetype.a > > /usr/lib/libfreetype.la (Yes, I've heard of libtool.) > > /usr/lib/libfreetype.so@ > > /usr/lib/libfreetype.so.6@ > > /usr/lib/libfreetype.so.6.3.10 > > > > > > > > % more /usr/lib/libc.so > > /* GNU ld script > > Use the shared library, but some functions are only in > > the static library, so try that secondarily. */ > > OUTPUT_FORMAT(elf64-x86-64) > > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > > /lib/ld-linux-x86- > > 64.so.2 ) ) > > > > > > > > % ls /lib/libc* > > /lib/libc.so.6@ > > > > > > etc. > > > > > > so I amend the previous to 5.8.1 on Linux also, and check what other > > systems do. > > > > > > > > > > But really, the first suggestion -- no versions. > > > > > > > > > > I wouldn't mind dropping the "lib" prefix but I think that breaks the > > static vs. dynamic probing that occurs on Darwin and maybe others. > > Though we do our own thing on Windows with Modula-3 where have > > foo.lib dynamic > > foo.lib.sa standalone > > > > > > > > > > and the Quake code handles the probing. > > > > > > > > > > It should be further noted that various systems including Linux, > > Solaris, and I believe > > some of the BSDs have yet another versioning mechanism in use, > > where, roughly speaking, > > functions get version names appended to them, but that is not > > visible at the source level, > > not even with #defines or #pragmas or inlines, though there is some > > of that too. > > > > > > > > > > Therefore, they can and do rev file names much less frequently than > > one might expect > > if one only knew about the use of version numbers in file names. > > > > > > > > > > I note this as sort of a counterpoint to the assertion that we > > should follow the conventions, > > because, arguably, we aren't fully following them, and probably never will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:40:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:40:41 +0000 Subject: [M3devel] cm3ide crash In-Reply-To: <4A607F8E.1E75.00D7.1@scires.com> References: <4A607F8E.1E75.00D7.1@scires.com> Message-ID: I admit I might have increased the problems. I'll try again with my config file fixes. Truncated stuff: There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer. I use TextWrangler, which provides /usr/bin/edit. It's not very good, but it is the best I have found on the Mac. (Visual C++ 5.0 is the best editor I have ever used by far; I use it every day; I'll try it in VMware.) A popular one might be: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode or arch -i386 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode It crashed the first time I ran it but seemed ok after that. And maybe still CodeWarrior, I can maybe get some paths for it if you want. And maybe BBEdit, I can try a trial version. Komodo. In general of course, many. - Jay Date: Fri, 17 Jul 2009 13:41:57 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] cm3ide crash Jay: I've not seen the whole of your message yet; I've received multiple truncated copies. Recall that CM3IDE is the open-source version of "Reactor". Reactor was tightly woven into the CM3 4.1 commercial release. During the install process, cm3install actually adjusted the cm3.cfg file to reflect the installation location, location of your preferred browser, preferred editor, etc. I know you don't use cm3install, and you've made changes to the cm3.cfg files, so if some of this stuff isn't going to be there going forward, I need to make adjustments to CM3IDE. When CM3IDE runs, if it doesn't find these variables in the cm3.cfg file, it tries to locate the appropriate stuff, hence the "CAUTION" messages you saw on stdout. In some cases, it asks the same type question that cm3install would have asked about the editor et al, then saves this information in its configuration file located in the user's home folder. Once the info is saved, it won't prompt you for it again. The error you are getting about the examples folder is probably due to you not copying this folder into your CM3 tree. There are README files explaining all this. If you don't have the examples folder, CM3IDE will still function, except you won't be able to build any of the examples. The examples are all pretty neat IMO, and CM3IDE actually builds them in your private workspace, so you can edit the sources and play around with them without affecting anyone else who wants to try out the examples. Each user gets a fresh copy from the examples folder. Not sure about the crash you are reporting, whether it is due to some problem with your cm3.cfg or your installation or just a bug. I don't experience this crash on Windows, but I have not rebuilt CM3IDE against the latest source tree yet. Perhaps a recent change to the source tree has impacted CM3IDE. I'm supposed to go rafting and camping this weekend with my son's Boy Scout troop, so I don't think I'll have much time to work on this problem. If I get back early, I'll try to look at the problem Sunday evening. Regards, Randy Coleburn >>> Jay K 7/17/2009 8:28 AM >>> I used cm3ide for a few minutes. I had to add BUILD_DIR explicitly to cm3.cfg. "Normally" (when compiling) it is constructed in a roundabout fashion by running the code. See m3-sys/cminstall/src/config-no-install/cm3.cfg for the config file I usually use. Clicking on the examples link: (gdb) r Starting program: /cm3/bin/cm3ide warning: posix_spawn failed, trying execvp, error: 86 CAUTION: PKG_USE not defined in cm3.cfg, constructed it from cm3.cfg path as: /cm3/pkg CAUTION: DOC_INSTALL not defined in cm3.cfg, constructed it from package root as: /cm3/doc NOTICE: Unable to locate 'examples' folder. Recovering user state from /Users/jay/proj/CM3_IDE.cfg0 calling start_browser(http://localhost:3800/) /Applications/Firefox.app/Contents/MacOS/firefox http://localhost:3800/ starting TCP service Scanning Packages: Jul 17 05:15... ?? b32e8e57 == cfe61f3f [Jay] Is this a problem? scan done: Jul 17 06:27 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 23997 thread 0x2703] 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x000000010012d3d9 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x00000001000c4d22 in Pathname__Absolute (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/PathnamePosix.m3:65 #2 0x00000001000c3c8d in FS__Iterate (M3_Bd56fi_pn=0x0) at ../src/os/POSIX/FSPosix.m3:243 #3 0x0000000100042713 in Roots__ScanExamples (M3_AnO5JK_self=0x100c72a78) at ../src/nodes/Roots.m3:1018 #4 0x0000000100042338 in Roots__ExamplesRootPage (M3_AnO5JK_self=0x100c72a78, M3_Ah9VqA_wx=0x101800018, M3_DLS2Hj_action=1, M3_AJUDqH_data=0x0) at ../src/nodes/Roots.m3:996 #5 0x000000010005abc0 in WebServer__ProcessRequest (M3_Bd56fi_cmd=0x100ce4c38, M3_Ah9VqA_wx=0x101800018) at ../src/misc/WebServer.m3:325 #6 0x000000010001e688 in TCPServer (M3_D2z1aq_self=0x100c541e8) at ../src/server/TCPServer.m3:116 #7 0x000000010011b52a in ThreadPThread__RunThread (M3_CgoaiZ_me=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x000000010011b1b6 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x100d02270) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #9 0x00007fff82a66deb in _pthread_start () #10 0x00007fff82a66cad in thread_start () There are other problems. It prompted me for my browser. On a Mac, it could offer choices like: jaypro:cm3ide jay$ find /Applications | grep -i fox$ /Applications/Firefox.app/Contents/MacOS/firefox jaypro:cm3ide jay$ find /Applications | grep -i fari$ /Applications/Safari.app/Contents/MacOS/Safari if they exist. Of course I should try Opera and whatever else and report their paths. I had to close any existing Firefox, else I got an error that only one Firefox can run at a time. The error came from Firefox, not cm3ide. For the prompt for editor, I grant there may be too many options to offer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 01:43:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 17 Jul 2009 23:43:38 +0000 Subject: [M3devel] cm3ide crash In-Reply-To: References: <4A607F8E.1E75.00D7.1@scires.com> Message-ID: [That was also truncated, but the direct send to Randy probably won't be..] > From: jay > To: rcoleburn; m3devel > Date: Fri, 17 Jul 2009 23:40:41 +0000 > Subject: Re: [M3devel] cm3ide crash > > I admit I might have increased the problems. I'll try again with my config file fixes. > Truncated stuff: > [deliberate snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 02:47:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 00:47:32 +0000 Subject: [M3devel] This is a new problem in I386_DARWIN tinderbox: In-Reply-To: References: <51B4144D-0BB7-446B-AE01-20A6A181748A@cs.purdue.edu> <4A60B629.1E75.00D7.1@scires.com> Message-ID: Oh darn I also forgot about the m3overrides files. Anywhere I added import("m3quake") needs override(ROOT, "m3-sys/m3quake") or such in the m3overrides -- whatever the existing quake users have (e.g. m3-sys/cm3). I can't get to that now. Can anyone else? Else much later today/tonight/tomorrow. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Fri, 17 Jul 2009 23:20:02 +0000 > Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: > > > > > > > > > Ok sorry I think I understand this all much better now and it should work now. Please let's see how the next runs go. > > > > - Jay > > > ________________________________ > > Date: Fri, 17 Jul 2009 17:34:57 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] This is a new problem in I386_DARWIN tinderbox: > > > I wonder if this problem may explain the CM3IDE crash that Jay reported because CM3IDE also parses the source files and probably relies on same underlying code. > > Regards, > > Randy Coleburn > >>>> Tony Hosking 7/17/2009 1:57 PM>>> > > It seems worrisome that m3tohtml is failing. > > 34147 HTML package report in /var/folders/Q6/Q6Pde0r5EY8Wa1mK8uCAxk+++TI/-Tmp-//cm3-pkg-report-I386_DARWIN-2009-07-17-06-27-10.html > 34148>>> 1 errors in test_m3_all_pkgs 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 > 34149 === 2009-07-17 06:30:30 cm3 package status run done > 34150 === 2009-07-17 06:30:30 build HTML package doc in /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 with lastok version > 34151 > 34152 > 34153 *** > 34154 NEXT *** runtime error: > 34155 *** Segmentation violation - possible attempt to dereference NIL > 34156 *** pc = 0x9be89f = Length + 0x24 in ../src/text/Text.m3 > 34157 *** > 34158 > 34159 regression-scripts/defs.sh: line 712: 8315 Broken pipe yes > 34160 8316 Abort trap | m3tohtml -dir html $pkgs > 34161>>> errors in test_m3tohtml 2009-07-17-05-15-06 /Users/hosking/work/cm3-ws/tv-2009-07-17-05-15-06 > 34162 === 2009-07-17 06:30:30 m3tohtml run done > From jay.krell at cornell.edu Sat Jul 18 02:20:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 17 Jul 2009 17:20:07 -0700 Subject: [M3devel] gdb on Darwin In-Reply-To: References: Message-ID: <03AC38D3-6818-4D1B-9B53-33582010D25B@hotmail.com> Wait a sec actually the problem might be larger here. Apple has its own object and executable format. I think its own static linker. I think a very old fork of gas. We don't care particularly about 'binutils' but it apparently intersects with gdb in bfd. There is investigation to be done but it wouldn't surprise me if this is a large permanent fork. - Jay (phone) On Jul 17, 2009, at 4:27 PM, Jay K wrote: > Apple doesn't push up all its changes, I think because they think/ > know they wouldn't all be accepted. > But granted, actually just supporting a target, should be acceptable. > Problems may be more like language changes for Mac source compat, > though I'd think with flags to turn them off/on, they'd be ok, but > that's another point. > > The lag does seem severe here though. > I guess wait for the gdb 7.0 release and then reevaluate? > In the meantime, no m3gdb for I386_DARWIN, AMD64_DARWIN. > I haven't tried PPC_DARWIN yet. > > I agree the forking is unfortunate. > Even if it is temporary, it seems to go too long. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Fri, 17 Jul 2009 09:50:36 -0400 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] gdb on Darwin > > > > Let's avoid pandering to Apple's forks. Better to upgrade to FSF > > sources that (eventually) should catch up. > > > > Sent from my iPhone > > > > On Jul 17, 2009, at 8:46 AM, Jay K wrote: > > > > > Even current FSF gdb 6.8 doesn't built on Darwin/x86 or Darwin/ > AMD64. > > > AMD64 gives and error that BFD is not supported. > > > x86 skips the critical gdb directory because it isn't supported. > > > > > > If we want this to work, we should probably the importing Apple's > > > fork? > > > Like I did for ARM_DARWIN m3cc? > > > > > > - Jay > > > > > > > > > From jay.krell at cornell.edu Sat Jul 18 03:55:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 01:55:37 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> Message-ID: > Well, it would be great if somebody could > > (a) provide a short update for the release notes regarding LONGINT and > (b) put this into two or three paragraphs (perhaps in their own > document) that ordinary users may understand and want to know > > Olaf There is a new type LONGINT. It is a 64bit signed integer on all platforms except the native NT "NT386" platform. On NT386 is a 32bits, for now, but we would like to fix that. or There is a new type LONGINT. >> Abstractly, it is a signed integer type with at least as many bits as INTEGER. Concretely it is a 64bit signed integer on all platforms except the native NT "NT386" platform. On NT386 is a 32bits, for now, but we would like to fix that. -- end of relnote, begin commentary -- Depending on some philosophy. Personally I adhere to a simpler philosophy where most integer types are of a fixed known size and will never ever change, you might as well encode the size in the name and use just those types -- int8_t, int16_t, in32_t, int64_t or INT8, INT16, INT32, INT64. And then some other types are exactly the same size as a pointer -- ptrdiff_t, size_t, Modula-3 INTEGER -- and will shrink/grow to fit. And there only exists "flat" address spaces. There is the other philosophy that merely states minimum sizes for all the types and an ordering among them, that allows for, say, every integer type to be 64 bits and many other configurations. - Jay From jay.krell at cornell.edu Sat Jul 18 10:25:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 08:25:06 +0000 Subject: [M3devel] hard link commands in quake? Message-ID: Should we keep the hard link commands in quake or not? They've only been there a short time, they were seen to work, and they are no longer used. Perhaps folks will end up wanting them for some reason?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 11:38:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 11:38:21 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <20090717225623.GA12084@topoi.pooq.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <20090717225623.GA12084@topoi.pooq.com> Message-ID: <20090718113821.ojh9fa6lkoko4gkc@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Current information on Modula 3 is still hard to get, Googling 'Modula > 3' still give a lot of links to obsolete information. Perhaps I could > update the Wikipedia entry to point to http://www.opencm3.net/releng/ as > the place to find information on current development? I know it's only > there temporarily, but it's always possible to update it when it moves > to its permanent place. > > Uh ... That is the proper place right now, isn't it? There are currently two domains associated with M3: www.modula3.org (formerly m3.org) www.opencm3.net (cm3 development) These should be used and known. Recently we were able to secure modula3.com, but I'd like to reserve this for other uses. Of course the old elegosoft links still work, too: modula3.elegosoft.com/{cm3,pm3} should be valid. > If you approve, I'll do it the next time I'm online long enough > (which may not be for a few days; I'm travelling). Unless someone beats > me to it, of course. (hint, hint) Just go ahead... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:36:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:36:16 +0200 Subject: [M3devel] Release notes comments In-Reply-To: <4A607BEF.1E75.00D7.1@scires.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> Message-ID: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Quoting Randy Coleburn : > 1. The section on "Package", particularly the first paragraph, I > think is a bit confusing. The CM3IDE documentation includes a lot > of information on packages, so perhaps the missing link in this > section should reference that documentation. To me, a package is a > set of sources that together represent one compilation unit for the > purpose of building a library, program, or other assemblage of > information (e.g., documentation). Each package resides in a > directory (folder), with sources and generated files in > subdirectories (sub folders) of the package's folder. In the > top-level CM3 source tree, packages are grouped into categories, > with each category represented by a subfolder rooted in that > top-level, and the packages comprising each category rooted in the > category's folder. Actually that part was copied from an older document by Neels, I think. What's the exact link you have i nmnd? http://www.opencm3.net/doc/help/cm3/packages.html? > 2. I presume that we do intend to make NT386 available for this > release, even though it says "Not Available Yet". Yes. Nobody has built any though. You or Jay may want to do that once we have fixed RC2. > 3. I find the "-bin-min-" and "-bin-core-" terminology a bit > confusing. To me, the "core" of something is the "heart" or > "minimal" part of it. Would it make more sense to rename > "-bin-core-" to "-bin-std-"? Indeed the explanation given for > "core" says in one place that it represents a "standard" > installation. In another place it is called "package pool". Also, > "min" in one place is called the "central installation hierarchy". > Suggest we be consistent. To me it makes more sense to have "min" > represent the "minimal installation" and "std" the "standard > installation" and "all" represents "everything." I grant it may be confusing, but am somewhat reluctant to change that now. It's legacy from the older package collections (all defined in pkginfo.txt) and used by a lot of scripts, IIRC. We have a `standard' collection there, too, but that has grown to `all' in the meantime. `min' was always the smallest possible installation (just cm3, m3core, libm3). `core' could be thought of as the packages needed to build the system itself (plus some useful libraries :-/). You're right, it's not really accurate, but I'd rather not change it for this release. Anybody's welcome to do it afterwards. Perhaps we could improve the explanation on the web pages? > 4. I don't understand the "-bin-ws-" concept of "precompiled user > workspace" and how it would be useful. Please elaborate. Copied from a mail I sent to Jay some weeks ago: ---- The idea was to reduce the number of packages, as M3 does not really support the separation of source and derived files for binary packages. So why not just enrich the source with just the products needed for shipping? This is sort of the smallest supported _M3_-binary package. Both system-dependent source and binary packages can be based on the same collection of ws packages. Traditionally CM3 offered only sources packages except for the minimal installation archive. There were lots of problems with o people understanding how to compile the source and o actual compilation errors due to miscellaneous causes People wanted something that is easy to install (without using lots of complex scripts). So I extended the standard cm3 builder so it can be used for such an installation. These are exactly the ws archives. M3 source and derived files which are needed for shipping an M3 package, but not more. I found that rather nice. ---- Does that make it clearer? > 5. All of the instructions seem to apply for UNIX-like > environments. We need to augment these to include how to do it on > non-Unix environments, such as Windows. For the scripts, like > "install.sh", do we intend to provide Windows command/batch files, > e.g. "install.cmd" or "install.bat"? Yes, I haven't spent much thought on Windows until now. I hoped that you or Jay will do that. Of course I've also overseen the install.cmd scripts for Windows :-/ Should we use cmd or bat? Could somebody quickly provide the equivalent of this loop, so that I can automate it? ---- #!/bin/sh HERE=`pwd` for p in m3-win/import-libs ... m3-comm/tcp; do cd $p cm3 -ship ${SHIPARGS} cd $HERE done ---- > 6. When we finally settle on a release name, need to update the > names in these instructions, e.g., replace "d5.8.1-RC1" under > "Installation Procedure", and "RC1" in other places. Much of the RCs is generated, but we'll probably have to replace some manually. > 7. "Installation Procedure" step #5, change "shop" to "ship". done > 8. "In case of problems" step #4, last line, change "volunteers" to > "volunteer" and change "his" to "his/her". done > Hope some of this helps. Sure. Updates are online and checked-in. Thanks for the comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:45:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:45:24 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090716173929.GB9087@topoi.pooq.com> References: <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> <20090630175228.GA16767@topoi.pooq.com> <20090716173929.GB9087@topoi.pooq.com> Message-ID: <20090718124524.4p91p1m0e8sw4404@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Jun 30, 2009 at 01:52:28PM -0400, hendrik at topoi.pooq.com wrote: >> On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: >> > >> > If it now just works and the problem cannot be reproduced, we should >> > leave it that way. I wouldn't invest much time on chasing down such >> > a spurious error now. >> >> OK. I'll take a look at installation instructions for some of the other >> packages, such as the one with Trestle. >> >> -- hendrik > > Installed the collection m3gdb from archive > cm3-bin-ws-m3gdb-LINUXLIBC6-d5.8.1-RC1.tgz; it installed flawlessly on > Debian squeeze (32-bit intel). > > Did the same for m3gui, had a glitch. It's at the end of the shell log > below. I've provided the entire log, starting with untarring the > archive, in case you need context. I think that's already fixed and should not occur with the next archive set. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 12:52:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 12:52:27 +0200 Subject: [M3devel] Request web page updates In-Reply-To: <670632.92136.qm@web56801.mail.re3.yahoo.com> References: <670632.92136.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090718125227.utf4lmyigwss0s48@mail.elegosoft.com> Hi Peter, thanks for the concrete suggestions. There are no RC2 packages yet, because there have been changes and further problems. Of course we'll have to adapt the web presentation, but I'd like to wait until the packages are there. If you like, you can already make changes to the pages checked-in to cm3/www though. www.opencm3.net/releng is not publicly linked by intention yet. I'm not sure if we can release RC2 this weekend, and I'm really busy during the week. I'll provide a status list from my point of view to better coordinate things. Thanks again, Olaf Quoting Peter Eiserloh : > Hi Olaf, > > Lets try to get the web site into "ship shape", getting ready > for visitors coming to check us out, after reading about the > latest release. Can your servers handle the Slashdot effect? > > Anyways, here are a few suggestions. > > > 1 - Downloads: Could you put a link to the tarball for the > 5.8.x release canididate (RC2) onto the web server, more > specifically on > > http://opencm3.net/download.html > > Once, the final version if 5.8.x is released, remove the link to the > RCx tarball, in favor of a permanent link to that final release, > just like the 5.4 release. > > > 2 - News: (a) It would also be very nice if the "home" or start page > brings up "news" items. I always forget to look at the > current news page. Actually I just discovered that it is > there. > > (b) You should add a news item promoting the use of the release > candidate, to help expose any regressions before the final > release. > > (c) The major changes to the compiler should be listed > somewhere, since the last release shown on the download > page. Right now the last release indicated is 5.4. > There are some snapshots of 5.5, but not final release > of 5.5. > > > 3 - About-CM3: The "About CM3" page, should have a section > listing all the changes / enhancements to the language that > it accepts vice that described in the language reference > from Nelson's SPWM3. > > For example, WIDECHAR, LONGINT are two new primitive types. > > Also list all the pragmas recognized by the compiler as > that is a compiler unique issue. > > http://opencm3.net/about-cm3.html > > It should also list all the architectures that are supported > by the compiler. These should always reflect those of the > latest "release" version of the compiler. > > > 4 - FAQ: Is there a way to get a single page for the FAQ > for the FAQ, one that is easy to print? > > I haven't had the time to look it over yet, so in time, > I will be asking "questions", that we may want to add > as FAQ items. > > > 5 - ROADMAP: We should have a page on which we record > suggestions for changes to the compiler, libraries, and > build system. This should capture the long term goals > which require thinking and concurrence among the community. > Simple things such as bug fixes would not be listed here. > > These requested changes (and amendments to them), could > then be prioritized, and tracked. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 13:42:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 11:42:29 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: > > 4. I don't understand the "-bin-ws-" concept of "precompiled user > > workspace" and how it would be useful. Please elaborate. > > Copied from a mail I sent to Jay some weeks ago: I actually still don't understand that. Archiving up the installed form includes source. What is the value of doing the ship/directory reorganization upon install? However, it is kind of a step toward a distribution that includes assembly for everything and then assemble, c compile, link, and ship on the target. (You might even use autoconf/libtool, though their powers will be severely constrained by the presence of assembly.) And such a distribution is easily cross built for all targets in one fell automated swoop on one host, good, valuable that way. > Yes, I haven't spent much thought on Windows until now. I hoped that > you or Jay will do that. Of course I've also overseen the install.cmd > scripts for Windows :-/ Should we use cmd or bat? Could somebody > quickly provide the equivalent of this loop, so that I can > automate it? There are recent builds on http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip as well as: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PPC_LINUX-d5.8.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PPC_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PPC_LINUX-d5.8.1.deb http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PPC_LINUX-d5.8.1.tar.gz etc. sorry.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 13:56:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 13:56:25 +0200 Subject: [M3devel] Release notes comments In-Reply-To: References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> Quoting Jay K : >> > 4. I don't understand the "-bin-ws-" concept of "precompiled user >> > workspace" and how it would be useful. Please elaborate. >> >> Copied from a mail I sent to Jay some weeks ago: > > I actually still don't understand that. Strange. > Archiving up the installed form includes source. No, only partial sources (historically the IFs, in CM3 modules, too -- but no makefiles for example). > What is the value of doing the ship/directory reorganization upon install? Easiest way to combine complete _usable_ source and binary products. > However, it is kind of a step toward a distribution that includes assembly > for everything and then assemble, c compile, link, and ship on the target. > (You might even use autoconf/libtool, though their powers will be severely > constrained by the presence of assembly.) > And such a distribution is easily cross built for all targets in one > fell automated > swoop on one host, good, valuable that way. > >> Yes, I haven't spent much thought on Windows until now. I hoped that >> you or Jay will do that. Of course I've also overseen the install.cmd >> scripts for Windows :-/ Should we use cmd or bat? Could somebody >> quickly provide the equivalent of this loop, so that I can >> automate it? > There are recent builds on > http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > > as well as: > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb [...] > > sorry.. That's not what we're talking about. We're talking about installation archives for Windows for RC2 as they are described in the release notes. There are none. I can build them myself, but then it will take another couple of weeks. No hurry needed though, as we haven't fixed RC2 yet. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 14:12:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:12:48 +0000 Subject: [M3devel] Release notes comments In-Reply-To: <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> <20090718135625.knafxdwyasso4oc4@mail.elegosoft.com> Message-ID: "usable source" as in editable and then rebuildable? Ok, that I see. > No, only partial sources (historically the IFs, in CM3 modules, too -- I didn't realize the history but I did notice the option and considered it to shrink the distributions, but the source is useful for debugging. > but no makefiles for example). To serve as examples and to make it buildable? Ok. Then I like it. :) Like, it is gentler than having newbies use cvs, and gets the versions that match their binaries. Change the release notes? Well, er, um, I guess the "ws" form on Windows might be nice too. You can say this: install.cmd: SetLocal set root=%~dp0 set pkgs= set pkgs=%pkgs% m3-sys/cm3 set pkgs=%pkgs% m3-sys/m3quake set pkgs=%pkgs% m3-libs/m3core etc. for %%a in (%pkgs%) do call :F1 %%a || exit /b 1 goto :eof :F1 set b=%1 rem replace forward slashes with backward slashes set b=%b:/=\% cd %root%\%b% || exit /b 1 cm3 -ship || exit /b 1 goto :eof There is an implied label :eof at the end of files. "goto :eof" is how you "return". You can also create pkgs.txt: m3-sys/cm3 m3-sys/m3quake etc. install.cmd SetLocal set root=%~dp0 for /f %%a in (%root%\pkgs.txt) do call :F1 %%a || exit /b 1 goto :eof :F1 set b=%1 rem replace forward slashes with backward slashes set b=%b:/=\% cd %root%\%b% || exit /b 1 cm3 -ship || exit /b 1 goto :eof I guess ideally pkgs.txt is identical files across all platforms, though maybe alter the newlines, and then you write install.sh and install.cmd that are constant and look for pkgs.txt "next to" them? This "advanced" sort of cmd won't work on Win9x but it should work pretty far back on NT like to 4.0 or maybe 3.51. For Win9x compat, and actual even for sanity, you'd might want to consider install.js or install.vbs. .js is a pretty ok language and .cmd is awful after a few lines. I guess I'll do this -- install.cmd + pkgs.txt. - Jay > Date: Sat, 18 Jul 2009 13:56:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Release notes comments > > Quoting Jay K : > > >> > 4. I don't understand the "-bin-ws-" concept of "precompiled user > >> > workspace" and how it would be useful. Please elaborate. > >> > >> Copied from a mail I sent to Jay some weeks ago: > > > > I actually still don't understand that. > Strange. > > > Archiving up the installed form includes source. > No, only partial sources (historically the IFs, in CM3 modules, too -- > but no makefiles for example). > > > What is the value of doing the ship/directory reorganization upon install? > Easiest way to combine complete _usable_ source and binary products. > > > However, it is kind of a step toward a distribution that includes assembly > > for everything and then assemble, c compile, link, and ship on the target. > > (You might even use autoconf/libtool, though their powers will be severely > > constrained by the presence of assembly.) > > And such a distribution is easily cross built for all targets in one > > fell automated > > swoop on one host, good, valuable that way. > > > >> Yes, I haven't spent much thought on Windows until now. I hoped that > >> you or Jay will do that. Of course I've also overseen the install.cmd > >> scripts for Windows :-/ Should we use cmd or bat? Could somebody > >> quickly provide the equivalent of this loop, so that I can > >> automate it? > > > There are recent builds on > > http://modula3.elegosoft.com/cm3/uploaded-archives/index.html. > > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > > > > as well as: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.8.1.deb > [...] > > > > sorry.. > > That's not what we're talking about. We're talking about installation > archives for Windows for RC2 as they are described in the release > notes. There are none. > > I can build them myself, but then it will take another couple of weeks. > No hurry needed though, as we haven't fixed RC2 yet. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:17:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:17:03 +0000 Subject: [M3devel] crossing from 64bit to 32bit? Message-ID: There appears to be a problem cross building from a 64bit host to a 32bit target. For example host=AMD64_DARWIN, target=PPC_DARWIN: == package /dev2/cm3/m3-sys/m3back == +++ /cm3/bin/cm3 -build -override -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=2009-05-16 @M3novm -boot -keep +++ --- building in PPC_DARWIN --- "../src/M3x86.m3", line 1549: set domain too large "../src/M3x86.m3", line 1570: set domain too large *** *** runtime error: *** An array subscript was out of range. *** file "../src/exprs/SetExpr.m3", line 701 *** I guess I should look at it.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 14:18:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 14:18:22 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king Message-ID: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> We really need to use some tools to help us keep (or gain?) control of the release process. Trac has been available for more than a year, but nobody has actively used it. Maybe this is a good time now :-) I've started by sketching a roadmap with RC2, 5.8 and 5.9. See here: https://projects.elego.de/cm3/roadmap Please add all the problems that were just reported via mail to the trac database with `new ticket': https://projects.elego.de/cm3/newticket. I've tried it for the cm3ide crash (ticket 1002); it seems to work fine. Some older bug reports are also still unresolved, but we can check them later. It would also be helpful if all active developers had personalized access and would help updating the tickets and the WiKi. Please send mail to admins(at)elego.de to obtain an account from Michael or Joffrey. Please let's use this; I'm afraid we'll lose control without it. It also has the advantage that the HTTP GUI is accessible from the customer network I'm usually working on (while everything else is blocked). Thanks in advance for your cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 18 14:17:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:17:28 +0000 Subject: [M3devel] crossing from 64bit to 32bit? Message-ID: (same thing crossing to I386_DARWIN) From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: crossing from 64bit to 32bit? Date: Sat, 18 Jul 2009 12:17:03 +0000 There appears to be a problem cross building from a 64bit host to a 32bit target. For example host=AMD64_DARWIN, target=PPC_DARWIN: == package /dev2/cm3/m3-sys/m3back == +++ /cm3/bin/cm3 -build -override -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.1 -DCM3_VERSION_NUMBER=050801 -DCM3_LAST_CHANGED=2009-05-16 @M3novm -boot -keep +++ --- building in PPC_DARWIN --- "../src/M3x86.m3", line 1549: set domain too large "../src/M3x86.m3", line 1570: set domain too large *** *** runtime error: *** An array subscript was out of range. *** file "../src/exprs/SetExpr.m3", line 701 *** I guess I should look at it.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:27:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:27:46 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: My opinion on some of these: cm3ide crash (NIL pointer?) #1002 probably fixed but needs retesting m3tohtml crash probably fixed but needs retesting broken m3overrides probably fixed but need to wait for Tinderbox to confirm I can migrate more of them to the one master, but that's not required. And there are some variations that need to be preserved, so it has to be all human reviewed. remove/simplify dynamic library version numbering? Can be left alone. I advocate removing the versions entirely. However the "complexity" here is very hidden anyway. m3gdb doesn't build on Darwin I think we punt on this for this release. Just update the distribution building to skip it. I think the fix is probably to import Apple's fork. I don't like it either, but it's probably the "best" way (short of the unlikely Apple/FSF merge). mentor startup crash on Darwin PPC_DARWIN? All Darwin? ie: What I reported? Yes sounds bad. Maybe the same thing as formsedit. - Jay > Date: Sat, 18 Jul 2009 14:18:22 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: admins at elego.de > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > We really need to use some tools to help us keep (or gain?) > control of the release process. Trac has been available for more > than a year, but nobody has actively used it. Maybe this is a good > time now :-) > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > See here: https://projects.elego.de/cm3/roadmap > > Please add all the problems that were just reported via mail > to the trac database with `new ticket': > https://projects.elego.de/cm3/newticket. > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > fine. Some older bug reports are also still unresolved, but we can > check them later. > > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. > > Please let's use this; I'm afraid we'll lose control without it. > > It also has the advantage that the HTTP GUI is accessible from the > customer network I'm usually working on (while everything else is > blocked). > > Thanks in advance for your cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 14:58:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 12:58:29 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: > cm3ide crash still happens -- if /cm3/examples doesn't exist. Doesn't crash if empty /cm3/examples created. To get it to crash, click on the "examples" link. Now I can't debug it, gdb won't debug my AMD64 binary, wierd. > m3tohtml crash I was able to see it crash, and then not crash with my config file changes. Since it is run in the Tinderbox though, that should provide extra confirmation. remove/simplify dynamic library version numbering? > Can be left alone. I meant specifically for this release. For next release I'd like to reconsider. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Sat, 18 Jul 2009 12:27:46 +0000 CC: admins at elego.de Subject: Re: [M3devel] RC2 Release Engineering Status and Trac-king My opinion on some of these: cm3ide crash (NIL pointer?) #1002 probably fixed but needs retesting m3tohtml crash probably fixed but needs retesting broken m3overrides probably fixed but need to wait for Tinderbox to confirm I can migrate more of them to the one master, but that's not required. And there are some variations that need to be preserved, so it has to be all human reviewed. remove/simplify dynamic library version numbering? Can be left alone. I advocate removing the versions entirely. However the "complexity" here is very hidden anyway. m3gdb doesn't build on Darwin I think we punt on this for this release. Just update the distribution building to skip it. I think the fix is probably to import Apple's fork. I don't like it either, but it's probably the "best" way (short of the unlikely Apple/FSF merge). mentor startup crash on Darwin PPC_DARWIN? All Darwin? ie: What I reported? Yes sounds bad. Maybe the same thing as formsedit. - Jay > Date: Sat, 18 Jul 2009 14:18:22 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: admins at elego.de > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > We really need to use some tools to help us keep (or gain?) > control of the release process. Trac has been available for more > than a year, but nobody has actively used it. Maybe this is a good > time now :-) > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > See here: https://projects.elego.de/cm3/roadmap > > Please add all the problems that were just reported via mail > to the trac database with `new ticket': > https://projects.elego.de/cm3/newticket. > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > fine. Some older bug reports are also still unresolved, but we can > check them later. > > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. > > Please let's use this; I'm afraid we'll lose control without it. > > It also has the advantage that the HTTP GUI is accessible from the > customer network I'm usually working on (while everything else is > blocked). > > Thanks in advance for your cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 18 15:07:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 13:07:22 +0000 Subject: [M3devel] I386_DARWIN lastok TInderbox red but? Message-ID: The I386_DARWIN lastok build Tinderbox shows as red, but the log looks ok. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 18 16:37:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Jul 2009 10:37:31 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: On 18 Jul 2009, at 08:58, Jay K wrote: > > cm3ide crash > > still happens -- if /cm3/examples doesn't exist. Sounds like instructions need to be explicit to install/copy the examples directory. I've not yet tried cm3ide. > Doesn't crash if empty /cm3/examples created. > To get it to crash, click on the "examples" link. > Now I can't debug it, gdb won't debug my AMD64 binary, wierd. > > > m3tohtml crash > > I was able to see it crash, and then not crash with my config file > changes. > Since it is run in the Tinderbox though, that should provide extra > confirmation. > > remove/simplify dynamic library version numbering? > > > Can be left alone. > > I meant specifically for this release. > For next release I'd like to reconsider. > > > - Jay > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 18 Jul 2009 12:27:46 +0000 > CC: admins at elego.de > Subject: Re: [M3devel] RC2 Release Engineering Status and Trac-king > > My opinion on some of these: > > cm3ide crash (NIL pointer?) #1002 > > probably fixed but needs retesting > > m3tohtml crash > > probably fixed but needs retesting > > broken m3overrides > > probably fixed but need to wait for Tinderbox to confirm > I can migrate more of them to the one master, but that's not required. > And there are some variations that need to be preserved, so it has > to be all > human reviewed. > > remove/simplify dynamic library version numbering? > > Can be left alone. > I advocate removing the versions entirely. > However the "complexity" here is very hidden anyway. > > m3gdb doesn't build on Darwin > > I think we punt on this for this release. > Just update the distribution building to skip it. > I think the fix is probably to import Apple's fork. > I don't like it either, but it's probably the "best" way (short of > the unlikely Apple/FSF merge). > > > mentor startup crash on Darwin > > PPC_DARWIN? All Darwin? > ie: What I reported? > Yes sounds bad. > Maybe the same thing as formsedit. > > > - Jay > > > > Date: Sat, 18 Jul 2009 14:18:22 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: admins at elego.de > > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > > > We really need to use some tools to help us keep (or gain?) > > control of the release process. Trac has been available for more > > than a year, but nobody has actively used it. Maybe this is a good > > time now :-) > > > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > > See here: https://projects.elego.de/cm3/roadmap > > > > Please add all the problems that were just reported via mail > > to the trac database with `new ticket': > > https://projects.elego.de/cm3/newticket. > > > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > > fine. Some older bug reports are also still unresolved, but we can > > check them later. > > > > It would also be helpful if all active developers had personalized > > access and would help updating the tickets and the WiKi. Please send > > mail to admins(at)elego.de to obtain an account from Michael or > Joffrey. > > > > Please let's use this; I'm afraid we'll lose control without it. > > > > It also has the advantage that the HTTP GUI is accessible from the > > customer network I'm usually working on (while everything else is > > blocked). > > > > Thanks in advance for your cooperation, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 18 16:36:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Jul 2009 10:36:05 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> On 18 Jul 2009, at 08:27, Jay K wrote: > mentor startup crash on Darwin > > PPC_DARWIN? All Darwin? > ie: What I reported? > Yes sounds bad. > Maybe the same thing as formsedit. > This one is serious. It is a new bug as far as I know, since I had mentor running fine about a year or so ago. > > - Jay > > > > Date: Sat, 18 Jul 2009 14:18:22 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: admins at elego.de > > Subject: [M3devel] RC2 Release Engineering Status and Trac-king > > > > We really need to use some tools to help us keep (or gain?) > > control of the release process. Trac has been available for more > > than a year, but nobody has actively used it. Maybe this is a good > > time now :-) > > > > I've started by sketching a roadmap with RC2, 5.8 and 5.9. > > See here: https://projects.elego.de/cm3/roadmap > > > > Please add all the problems that were just reported via mail > > to the trac database with `new ticket': > > https://projects.elego.de/cm3/newticket. > > > > I've tried it for the cm3ide crash (ticket 1002); it seems to work > > fine. Some older bug reports are also still unresolved, but we can > > check them later. > > > > It would also be helpful if all active developers had personalized > > access and would help updating the tickets and the WiKi. Please send > > mail to admins(at)elego.de to obtain an account from Michael or > Joffrey. > > > > Please let's use this; I'm afraid we'll lose control without it. > > > > It also has the advantage that the HTTP GUI is accessible from the > > customer network I'm usually working on (while everything else is > > blocked). > > > > Thanks in advance for your cooperation, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 18 17:50:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 17:50:32 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> <9CD54E48-4CC0-44A3-85BC-0308CB96A69D@cs.purdue.edu> Message-ID: <20090718175032.cnrq4lyhcc48scog@mail.elegosoft.com> Quoting Tony Hosking : > On 18 Jul 2009, at 08:27, Jay K wrote: > >> mentor startup crash on Darwin >> >> PPC_DARWIN? All Darwin? >> ie: What I reported? >> Yes sounds bad. >> Maybe the same thing as formsedit. >> > > This one is serious. It is a new bug as far as I know, since I had > mentor running fine about a year or so ago. Thas was just my bad memory. These things happen without tracking tools. I meant formsedit (already corrected in WiKi). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 18:12:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 18:12:26 +0200 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <20090718181226.89oeqfagisggw8sw@mail.elegosoft.com> Quoting Olaf Wagner : > It would also be helpful if all active developers had personalized > access and would help updating the tickets and the WiKi. Please send > mail to admins(at)elego.de to obtain an account from Michael or Joffrey. I just learned how to add new users via command line, so please just let _me_ know if you want an account. The trac installation seems to be an older version with some bugs; an update will be done during the next weeks. o self administration does not work o adding of users via Admin does not work o generated links in mails are missing /cm3/ o probably more... We'll have to live with that for the next days. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 18 22:01:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Jul 2009 22:01:44 +0200 Subject: [M3devel] current tinderbox failures Message-ID: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> I386_DARWIN failed with regression-scripts/defs.sh: line 480: ./scripts/do-cm3-core.sh: No such file or directory I don't understand that (the script is definitely there in the repo) SOLgnu fails with Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/unix/solaris-2-x/Usignal.i3 *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/unix/solaris-2-x/Usignal.i3 *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? -DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? -DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? failed *** This must be a problem in the m3makefiles in m3core. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mbishop at esoteriq.org Sat Jul 18 22:55:27 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Sat, 18 Jul 2009 15:55:27 -0500 Subject: [M3devel] It's good to be back! Message-ID: <4A6236BF.5060903@esoteriq.org> For some reason, I stopped getting m3devel messages...and when I sent an email asking if something was wrong with the list, my messages never got through...I checked the archive and saw lots of activity, but my messages never showed up...anyway, I just signed up with another email address, and am getting the messages again. Glad to see there is progress with a "real" release :) From jay.krell at cornell.edu Sun Jul 19 01:50:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 18 Jul 2009 23:50:13 +0000 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: > cm3ide crash > still happens -- if /cm3/examples doesn't exist. > Sounds like instructions need to be explicit to install/copy the examples directory. I've not yet tried cm3ide. Still, it should do better when the directory isn't there. Other directories probably too. I'm not a big fan of cm3ide, or any IDE these days really, but I'll try to stick to concrete problems, which are bound to be fairly small. cm3ide is quite unusual in being browser based and that really limits it, esp. targeting browsers from long ago with just a bunch of html, using Flash or Silverlight can result in a browser-based app as good as a non-browser-based app. I don't like IDEs because..long winded, not sure anyone cares..I saved my notes in case anyone does.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 08:02:26 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 18 Jul 2009 23:02:26 -0700 Subject: [M3devel] current tinderbox failures In-Reply-To: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> References: <20090718220144.jb8be5mar4sww0k0@mail.elegosoft.com> Message-ID: <7855629E-9E28-4A40-A299-2FF570FFFC1B@hotmail.com> My ppc Linux run hit the same file not found error. Sparc Linux failed because I gave it a bad cm3.cfg. Still that is great progress for running tinderbox.. - Jay (phone) On Jul 18, 2009, at 1:01 PM, Olaf Wagner wrote: > I386_DARWIN failed with > > regression-scripts/defs.sh: line 480: ./scripts/do-cm3-core.sh: No > such file or directory > > I don't understand that (the script is definitely there in the repo) > > SOLgnu fails with > > Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/ > unix/solaris-2-x/Usignal.i3 > *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/ > Fatal Error: duplicate unit: ../src/unix/Common/Usignal.i3 ../src/ > unix/solaris-2-x/Usignal.i3 > *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/ > niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? - > DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? $RARGS > && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/ > niagara-2009-07-18-15-09-35/cm3? -DCM3_VERSION_TEXT=?d5.8.2? - > DCM3_VERSION_NUMBER=?050802? -DCM3_LAST_CHANGED=?2009-07-15? failed > *** > > This must be a problem in the m3makefiles in m3core. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Sun Jul 19 17:44:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 15:44:40 +0000 Subject: [M3devel] "kext" In-Reply-To: <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> References: <20090715083140.48d9gla68w4kkwos@mail.elegosoft.com> <20090715113356.30raw28b74og08kk@mail.elegosoft.com> <20090715193501.csfu6jqjso4wk00o@mail.elegosoft.com> <20090716150558.4ns4krxzk8cooow4@mail.elegosoft.com> Message-ID: > I didn't think of that, but I don't think it matters; there is no > program named kext on Darwin, is there? kextd kextfind kextload kextstat but no kext. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Sun Jul 19 20:49:32 2009 From: rcolebur at scires.com (Randy Coleburn) Date: 19 Jul 2009 14:49:32 -0400 Subject: [M3devel] Release notes comments In-Reply-To: <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> References: <4A5E7496.7020308@cox.net> <20090716082422.jb2pqw5busg4g4os@mail.elegosoft.com> <06DEB539-6CC9-49B6-A876-9DB884A55207@cs.purdue.edu> <20090717185125.95jvxsgb2o84sc0c@mail.elegosoft.com> <4A607BEF.1E75.00D7.1@scires.com> <20090718123616.j1s1szx8g0sk8go0@mail.elegosoft.com> Message-ID: <4A63326E.1E75.00D7.1@scires.com> >>> Olaf Wagner 7/18/2009 6:36 AM >>> >Yes, I haven't spent much thought on Windows until now. I hoped that >you or Jay will do that. Of course I've also overseen the install.cmd >scripts for Windows :-/ Should we use cmd or bat? Could somebody >quickly provide the equivalent of this loop, so that I can >automate it? > ---- >#!/bin/sh >HERE=`pwd` >for p in m3-win/import-libs ... m3-comm/tcp; do >cd $p >cm3 -ship ${SHIPARGS} >cd $HERE >done > ---- Olaf: Your script can be expressed in Windows .CMD format as follows: REM ---BEGIN--- @echo off for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p goto End :ShipIt echo ...shipping %1... pushd %1 cm3 -ship %SHIPARGS% popd echo. goto :EOF :End echo done @echo on REM ---END--- Of course, the REM lines at the beginning/end are optional, I just put them there to show start/end of the script. Also, you would want to replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of folders to be processed. You can separate them by blank spaces or semi-colons, but if you have a path with an embedded space, you will need to put double quotes around the path. FYI: If your list of paths is in a text file, there is another form of the FOR command that would work to process the list from that file. I don't mind writing .CMD files, so if you and Jay want some help in this area, I am willing to volunteer. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From rcoleburn at scires.com Sun Jul 19 20:58:38 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 14:58:38 -0400 Subject: [M3devel] release testing on Windows XP Message-ID: <4A633472.1E75.00D7.1@scires.com> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Jul 19 22:55:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 16:55:53 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A633472.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> Message-ID: <4A634FED.1E75.00D7.1@scires.com> For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:31:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:31:50 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A634FED.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:33:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:33:14 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis Message-ID: I'm finally getting some progress here! http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1248027392.25281 sparc linux looks good http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248026305.31492 x86 linux unclear but maybe ok http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248022605.3042 ppc linux merge conflict in my PPC_LINUX config file, will try again The ./scripts/do-cm3-core.sh error: Look at the bottom of: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1248038292.4235#err2 pwd 22 /home/jay/work/cm3-ws/localhost-2009-07-19-21-15-43/cm3 23 ls 24 COPYRIGHT-BSD 25 COPYRIGHT-CMASS 26 COPYRIGHT-COLUMBIA 27 COPYRIGHT-DEC 28 COPYRIGHT-JDP 29 COPYRIGHT-PURDUE 30 COPYRIGHT-XEROX 31 COPYRIGHTS 32 CVS 33 README 34 caltech-parser 35 compat.quake 36 doc 37 m3overrides 38 ls ./scripts 39 NEXT ls: cannot access ./scripts: No such file or directory 40 === build core system with current compiler 41 NEXT regression-scripts/defs.sh: line 489: ./scripts/do-cm3-core.sh: No such file or directory Notice the majority of the source is missing, not just scripts. Maybe timing out during the cvs checkout? Maybe we should put in a few cvs -z3 upds at the end of it? Maybe ensure that cvs's exit code is checked? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 19 23:33:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:33:48 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A634FED.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: [truncated yet again..] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] release testing on Windows XP Date: Sun, 19 Jul 2009 21:31:50 +0000 Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay [deliberately truncated here] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at scires.com Sun Jul 19 23:43:02 2009 From: rcolebur at scires.com (Randy Coleburn) Date: 19 Jul 2009 17:43:02 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> Message-ID: <4A635B25.1E75.00D7.1@scires.com> do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Sun Jul 19 23:52:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 21:52:25 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A635B25.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> Message-ID: The "all" versions of all the scripts fail to compile (all as in Python, .sh, .cmd). Try "std". All the scripts are also a bit identically loose in how they find "projects". They look for something/src/m3makefile where something contains what they are after. It is a bit fragile. Except for your .cmd files which are more precise. There is also a bug in all the scripts that adding new packages to the source tree fails. The PKGS files needs a version number in its name and if PKGS-correctionversion doesn't exist the scripts should delete PKGS* and regenerate. We only recently got a centralized version file though and I didn't want to implement this until that was in. - Jay Date: Sun, 19 Jul 2009 17:43:02 -0400 From: rcolebur at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] release testing on Windows XP do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 00:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 22:48:24 +0000 Subject: [M3devel] Tinderbox missing do-cm3-core.sh Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039304.30290#err2 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039913.18931#err2 to more instances of missing do-cm3-core.sh. You can see in these cases the cvs checkout got much further, but still missed all of scripts. Scripts just happens to be alphabetically late so has a higher chance of not making it. Suggestions? Surely this is just as much likely flaky network on my end as anywhere else. Put a file "last" in the repository and if it is missing after checkout, abort and start over? Send the repository down as one large .tar.gz, and again, if failed to recieve, abort and start over? Could keeping a checkout and just updating it from run to run be made reliable/trusted enough? That would greatly mitigate network problems, make abort + retry less expensive. Or not much competition to the cleanliness of a whole new checkout for each build? Just run it all in an hourly loop and accept the lossage? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 00:50:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 19 Jul 2009 22:50:23 +0000 Subject: [M3devel] FW: Tinderbox missing do-cm3-core.sh Message-ID: [truncated again!] From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: Tinderbox missing do-cm3-core.sh Date: Sun, 19 Jul 2009 22:48:24 +0000 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039304.30290#err2 http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248039913.18931#err2 to more instances of missing do-cm3-core.sh. You can see in these cases the cvs checkout got much further, but still missed all of scripts. Scripts just happens to be alphabetically late so has a higher chance of not making it. Suggestions? Surely this is just as much likely flaky network on my end as anywhere else. Put a file "last" in the repository and if it is missing after checkout, abort and start over? Send the repository down as one large .tar.gz, and again, if failed to recieve, abort and start over? Could keeping a checkout and just updating it from run to run be made reliable/trusted enough? That would greatly mitigate network problems, make abort + retry less expensive. Or not much competition to the cleanliness of a whole new checkout for each build? Just run it all in an hourly loop and accept the lossage? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Jul 20 04:19:26 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 19 Jul 2009 22:19:26 -0400 Subject: [M3devel] release testing on Windows XP In-Reply-To: References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> Message-ID: <4A639BC0.1E75.00D7.1@scires.com> Ok, so here is what I've done: 1. deleted PKGS 2. scripts/win/upgrade.cmd 3. scripts/win/do-cm3-std.cmd These work, except that I had to modify pkginfo.txt as follows: 1. Removed all m3-www packages (web & proxy) 2. Removed all cvsup packages If I left these in there, I got failures. BTW, I've rebuilt cm3ide and it is running on Windows XP with no crashes so far. Now, if (?) the pkginfo.txt file is what is driving the process, it appears that each line in the file has a package and one or more tags, e.g. min std core. I assume the order of packages in pkginfo.txt is the correct build order. If these statements are true (and I'm asking you to verify), I will try to write a simpler CMD script that deals with the building process using pkginfo.txt as the "input control file". Regards, Randy Coleburn >>> Jay K 7/19/2009 5:52 PM >>> The "all" versions of all the scripts fail to compile (all as in Python, .sh, .cmd). Try "std". All the scripts are also a bit identically loose in how they find "projects". They look for something/src/m3makefile where something contains what they are after. It is a bit fragile. Except for your .cmd files which are more precise. There is also a bug in all the scripts that adding new packages to the source tree fails. The PKGS files needs a version number in its name and if PKGS-correctionversion doesn't exist the scripts should delete PKGS* and regenerate. We only recently got a centralized version file though and I didn't want to implement this until that was in. - Jay Date: Sun, 19 Jul 2009 17:43:02 -0400 From: rcolebur at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] release testing on Windows XP do-cm3-all.py: This crazy python animal is now trying to compile my examples folder! It fails, of course, and doesn't go any farther. Regards, Randy Coleburn >>> Jay K 7/19/2009 5:31 PM >>> Try deleting the PKGS file of course. Management of that file is poor, across all the scripts. Almost any version of Python will do and I highly recommend it. .cmd is a terrible programming language and Python is an excellent one. Python is also very portable. I use all the same automation across a variety of platforms. (I still haven't gotten it to work on OpenBSD/sgimips and I do sometimes test Olaf's .sh code.) JScript isn't so bad, and it is "built in" on essentially all Windows installs (as long as there is IE), but it isn't portable at all for command line use to Python wins again. I understand the desire to not install anything at all, but this one install provides tremendous value. Sometimes a dependency is worth it. - Jay Date: Sun, 19 Jul 2009 16:55:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com; rcoleburn at scires.com Subject: Re: [M3devel] release testing on Windows XP For #3 below, I went to scripts/win and ran upgrade.cmd. No problems there. Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www\web package is missing. I suspect these scripts may not be up to date. Alas, I'm going to try to download python 2.6 for Windows since that is what Jay seems to be using these days. Then I'll try running his python scripts and see how it fares. But, I again think we need to not depend on python scripts for cm3 on Windows. I am willing to work on the .CMD scripts. --Randy Coleburn >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> Olaf / Jay / et al: I am back from my trip and thought I would try to test out what we have for Windows XP platform. My plan is: 1. Backup my current cm3 tree and sandbox. 2. Update my local sandbox copy of all CM3 from the CVS repository. 3. Use my current cm3 to rebuild everthing in the updated sandbox. In so doing, I will ship back to my cm3 installation thereby updating it to be current. 4. Use my updated cm3 to build and test a number of my programs. 5. Report results to m3devel Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 04:52:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 19 Jul 2009 19:52:07 -0700 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A639BC0.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> Message-ID: <5115ADEF-1DA5-473A-9B15-DD2753CA25D0@hotmail.com> Correct, pkginfo.txt defines the groups and the order. Search for pkginfo. I thought it already drives the .cmd code. Pylib.py has it's own copy but easy to fix. I don't remember but I might have left provision for filtering packages. Originally I wanted the filter conditions expressed somehow in pkginfo.txt but I never did that. - Jay (phone) On Jul 19, 2009, at 7:19 PM, "Randy Coleburn" wrote: > Ok, so here is what I've done: > 1. deleted PKGS > 2. scripts/win/upgrade.cmd > 3. scripts/win/do-cm3-std.cmd > > These work, except that I had to modify pkginfo.txt as follows: > 1. Removed all m3-www packages (web & proxy) > 2. Removed all cvsup packages > > If I left these in there, I got failures. > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > crashes so far. > > Now, if (?) the pkginfo.txt file is what is driving the process, it > appears that each line in the file has a package and one or more > tags, e.g. min std core. I assume the order of packages in > pkginfo.txt is the correct build order. If these statements are > true (and I'm asking you to verify), I will try to write a simpler > CMD script that deals with the building process using pkginfo.txt as > the "input control file". > > Regards, > Randy Coleburn > > >>> Jay K 7/19/2009 5:52 PM >>> > The "all" versions of all the scripts fail to compile (all as in > Python, .sh, .cmd). > Try "std". > > All the scripts are also a bit identically loose in how they find > "projects". > They look for something/src/m3makefile where something contains > what they are after. > It is a bit fragile. > Except for your .cmd files which are more precise. > > There is also a bug in all the scripts that adding new packages to > the source tree fails. > The PKGS files needs a version number in its name and if PKGS- > correctionversion doesn't > exist the scripts should delete PKGS* and regenerate. > We only recently got a centralized version file though and I didn't > want to implement > this until that was in. > > - Jay > > > Date: Sun, 19 Jul 2009 17:43:02 -0400 > From: rcolebur at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] release testing on Windows XP > > do-cm3-all.py: This crazy python animal is now trying to compile my > examples folder! > It fails, of course, and doesn't go any farther. > Regards, > Randy Coleburn > > >>> Jay K 7/19/2009 5:31 PM >>> > Try deleting the PKGS file of course. Management of that file is > poor, across all the scripts. > Almost any version of Python will do and I highly recommend it. .cmd > is a terrible programming language and Python is an excellent one. > Python is also very portable. I use all the same automation across a > variety of platforms. > (I still haven't gotten it to work on OpenBSD/sgimips and I do > sometimes test Olaf's .sh code.) > JScript isn't so bad, and it is "built in" on essentially all > Windows installs (as long as there is IE), but it isn't portable at > all for command line use to Python wins again. I understand the > desire to not install anything at all, but this one install provides > tremendous value. Sometimes a dependency is worth it. > > - Jay > > Date: Sun, 19 Jul 2009 16:55:53 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com; rcoleburn at scires.com > Subject: Re: [M3devel] release testing on Windows XP > > For #3 below, I went to scripts/win and ran upgrade.cmd. No > problems there. > > Then I tried do-cm3-std.cm3, but it fails complaining that the m3-www > \web package is missing. > > I suspect these scripts may not be up to date. > > Alas, I'm going to try to download python 2.6 for Windows since that > is what Jay seems to be using these days. Then I'll try running his > python scripts and see how it fares. > > But, I again think we need to not depend on python scripts for cm3 > on Windows. I am willing to work on the .CMD scripts. > > --Randy Coleburn > > >>> "Randy Coleburn" 7/19/2009 2:58 PM >>> > Olaf / Jay / et al: > > I am back from my trip and thought I would try to test out what we > have for Windows XP platform. > > My plan is: > > 1. Backup my current cm3 tree and sandbox. > 2. Update my local sandbox copy of all CM3 from the CVS repository. > 3. Use my current cm3 to rebuild everthing in the updated sandbox. > In so doing, I will ship back to my cm3 installation thereby > updating it to be current. > 4. Use my updated cm3 to build and test a number of my programs. > 5. Report results to m3devel > > Regards, > Randy Coleburn From wagner at elegosoft.com Mon Jul 20 12:38:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 12:38:33 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: Message-ID: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Quoting Jay K : > Notice the majority of the source is missing, not just scripts. > > Maybe timing out during the cvs checkout? > Maybe we should put in a few cvs -z3 upds at the end of it? > Maybe ensure that cvs's exit code is checked? Yes, that should be checked (isn't it already?). Please add if it's missing. I think the problem may be that birch is operating under high load (at least has done all the weekend), and my attempts to do complete cm3 build didn't alleviate the situation ;-) There's something weird going on, but unfortunately our system administration people are scarce currently due to holidays... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 20 12:44:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 12:44:46 +0200 Subject: [M3devel] release testing on Windows XP In-Reply-To: <4A639BC0.1E75.00D7.1@scires.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> Message-ID: <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> Quoting Randy Coleburn : > Ok, so here is what I've done: > 1. deleted PKGS > 2. scripts/win/upgrade.cmd > 3. scripts/win/do-cm3-std.cmd > > These work, except that I had to modify pkginfo.txt as follows: > 1. Removed all m3-www packages (web & proxy) > 2. Removed all cvsup packages CVSup will not build on Windows and should be excluded on that platform, but why do the www packages fail? I thought they should be OK. Is there anything specific missing for them in Windows? > If I left these in there, I got failures. > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > crashes so far. Fine. Have you tried without the example folder, too? > Now, if (?) the pkginfo.txt file is what is driving the process, it > appears that each line in the file has a package and one or more > tags, e.g. min std core. I assume the order of packages in > pkginfo.txt is the correct build order. If these statements are > true (and I'm asking you to verify), I will try to write a simpler > CMD script that deals with the building process using pkginfo.txt as > the "input control file". Yes. Sounds right. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 12:55:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 10:55:57 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: > I think the problem may be that birch is operating under high load > (at least has done all the weekend), and my attempts to do complete > cm3 build didn't alleviate the situation ;-) > > There's something weird going on, but unfortunately our system > administration people are scarce currently due to holidays... Could be me?, esp. my repeated Tinderbox runs, doing cvs checkout over and over? No more than three concurrently and not in a loop, but stil.. Three: LINUXLIBC6, PPC_LINUX, SPARC32_LINUX. I can try just one at a time. And, I added -z3 to the checkout? Good/bad/other? gzip is supposedly very non-taxing and I think -z3 is like gzip. I've heard cvs is a cpu hog, it's one reason people switch away from it (which I hope we'll do after this release..) I'll check about the cvs exit code. A few times control-c-ed cvs and my birch ssh would show some errors on syslogd about cvs. - Jay From jay.krell at cornell.edu Mon Jul 20 13:07:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 11:07:21 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: Let's put the exclusions in the three or so m3makefiles instead of coming up with sh, python, and cmd. Just like win-libs only builds on Win32. Which reminds me I should put in the X filtering that way.. And m3gdb... And anything else that isn't really up to the user because the problems run fairly deep (in extreme cases, trying to fix such things, user can edit it away). (The Interix problem with X maybe doesn't run very deep, X is mostly there, but m3gdb on Darwin, cvsup probably NT386...) After this release I think we'll go ahead and unjoin the three NT386 platforms, and rename them all... - Jay ---------------------------------------- > Date: Mon, 20 Jul 2009 12:38:33 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] tinderbox status improvements/diagnosis > > Quoting Jay K : > >> Notice the majority of the source is missing, not just scripts. >> >> Maybe timing out during the cvs checkout? >> Maybe we should put in a few cvs -z3 upds at the end of it? >> Maybe ensure that cvs's exit code is checked? > > Yes, that should be checked (isn't it already?). Please add > if it's missing. > > I think the problem may be that birch is operating under high load > (at least has done all the weekend), and my attempts to do complete > cm3 build didn't alleviate the situation ;-) > > There's something weird going on, but unfortunately our system > administration people are scarce currently due to holidays... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 20 13:12:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 11:12:38 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720123833.c99uhmwhcs4sgww8@mail.elegosoft.com> Message-ID: wrong thread, this was about cvsup.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Mon, 20 Jul 2009 11:07:21 +0000 > Subject: Re: [M3devel] tinderbox status improvements/diagnosis > > > Let's put the exclusions in the three or so m3makefiles instead of coming up with sh, python, and cmd. Just like win-libs only builds on Win32. [snip] From wagner at elegosoft.com Mon Jul 20 13:51:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 13:51:09 +0200 Subject: [M3devel] Current CM3 test failures on AMD64_LINUX and FreeBSD Message-ID: <20090720135109.3etgatcn4w80w4gg@mail.elegosoft.com> Could anybody have a look at the test failures (red) in http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html? There are also several failures in http://www.opencm3.net/m3tests/m3tests-AMD64_LINUX-2009-07-20-06-12-30.html failures: 18 p009 needs to be adapted for 64 bit platforms (integer size). p040 number conversion routines ASCII <-> binary -- probably always a problem. Has anybody a good idea what to do here? p116b default IEEE floating point tests from Xerox PARC p126 REAL arithmetic p137 bit insert and extract -- probably a 32/64 bit issue, too? p172 REAL vs. C's float -- looks strange (wrong sign) p179 alignment of ARRAY OF BITS 32 FOR INTEGER -- package build failed p204 IP address initializers -- this looks more serious (assertion faiure) p206 ARRAY constructors in var decls using named open array types -- p.b.f. p207 subrange declarations -- p.b.f. p209 open array initializers compile failure -- assertion failure p210 open array initializers runtime failure -- NIL dereference? r002 stack overflow in the main thread -- bus error <-> segmentation fault r003 b3tests/b002 - improper size for an open array parameter -- 32/64 again? r004 negative size for an open array -- line number difference only e020 illegal recursive declaration -- p.b.f <-> segmentation fault e026 two types with the same brand -- empty??? e029 use type instead of value as an initializer -- p.b.f.: ** INTERNAL CG ERROR *** stack not empty, depth (1), looks serious For comparison, here are the failures on FreeBSD (14): p040 binary <-> ASCII conversion routines p116b default IEEE floating point tests from Xerox PARC p172 REAL vs. C's float p185 REAL vs. C float -- not on Linux p204 IP address initializers -- code generator failures p206 ARRAY constructors in var decls using named open array types p207 subrange declarations p209 open array initializers compile failure p210 open array initializers runtime failure r001 unhandled exception r004 negative size for an open array e020 illegal recursive declaration e026 two types with the same brand e029 use type instead of value as an initializer While some of these are probably only problems in the test code or method, it seems to me that we should have a closer look at all of them before the release. Explanations, adaptions of test code and cm3 fixes will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 14:38:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 12:38:31 +0000 Subject: [M3devel] release testing on Windows XP In-Reply-To: <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> References: <4A633472.1E75.00D7.1@scires.com> <4A634FED.1E75.00D7.1@scires.com> <4A635B25.1E75.00D7.1@scires.com> <4A639BC0.1E75.00D7.1@scires.com> <20090720124446.t0txxd8d6sooc088@mail.elegosoft.com> Message-ID: I excluded cvsup on Win32. Everything in m3-www builds ok for me. There is a crashing struct tm bug in the tree, I vaguely recall it was in one of these barely working web browsers. They assume struct tm is the BSDish one with extra stuff at the end, which is only true on some platforms. Oh, this stuff: :\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3 :\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3 typical unsafe Modula-3... - Jay > Date: Mon, 20 Jul 2009 12:44:46 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] release testing on Windows XP > > Quoting Randy Coleburn : > > > Ok, so here is what I've done: > > 1. deleted PKGS > > 2. scripts/win/upgrade.cmd > > 3. scripts/win/do-cm3-std.cmd > > > > These work, except that I had to modify pkginfo.txt as follows: > > 1. Removed all m3-www packages (web & proxy) > > 2. Removed all cvsup packages > > CVSup will not build on Windows and should be excluded on that > platform, but why do the www packages fail? I thought they should > be OK. > > Is there anything specific missing for them in Windows? > > > If I left these in there, I got failures. > > > > BTW, I've rebuilt cm3ide and it is running on Windows XP with no > > crashes so far. > > Fine. Have you tried without the example folder, too? > > > Now, if (?) the pkginfo.txt file is what is driving the process, it > > appears that each line in the file has a package and one or more > > tags, e.g. min std core. I assume the order of packages in > > pkginfo.txt is the correct build order. If these statements are > > true (and I'm asking you to verify), I will try to write a simpler > > CMD script that deals with the building process using pkginfo.txt as > > the "input control file". > > Yes. Sounds right. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 20 14:51:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 14:51:42 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis Message-ID: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Quoting Jay K : >> I think the problem may be that birch is operating under high load >> (at least has done all the weekend), and my attempts to do complete >> cm3 build didn't alleviate the situation ;-) >> >> There's something weird going on, but unfortunately our system >> administration people are scarce currently due to holidays... > > Could be me?, esp. my repeated Tinderbox runs, doing cvs checkout > over and over? > No more than three concurrently and not in a loop, but stil.. > Three: LINUXLIBC6, PPC_LINUX, SPARC32_LINUX. > I can try just one at a time. That should be normal business; I rather meant things like the three large bzip2 processes running all day for backup purposes and eating all the cpu time... > And, I added -z3 to the checkout? Good/bad/other? > gzip is supposedly very non-taxing and I think -z3 is like gzip. I found that it's often counter productive to use compression; however, most times small levels are more pratical, so I'd suggest you try -z1. > I've heard cvs is a cpu hog, it's one reason people switch away from > it (which I hope we'll do after this release..) Not that I know... it usually sleeps while waiting for file i/o. > I'll check about the cvs exit code. > > A few times control-c-ed cvs and my birch ssh would show some errors > on syslogd about cvs. Have seen those too yesterday... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 20 21:04:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 19:04:41 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: How do I get tinderbox to run the tests? It looks like maybe BUILD_REL=lastok does not but letting BUILD_REL default does. I'll fake up a 5.4 install with current files... Let it be known that "lastrel" builds might actually be "lastok" builds. If you can tell which ones are mine.. > I found that it's often counter productive to use compression; > ...so I'd suggest you try -z1. I'll change it later. You might have an unusual viewpoint though -- it is fast to checkout from birch to birch. -z3 is what I recall was recommended. > > I've heard cvs is a cpu hog, it's one reason people switch away from > > it (which I hope we'll do after this release..) I'll have to search, initial searches failed. > Not that I know... it usually sleeps while waiting for file i/o. True. > > I'll check about the cvs exit code. Fix attempted. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 20 21:56:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 19:56:00 +0000 Subject: [M3devel] tinderbox confusing bin and root? Message-ID: On three machines now I've seen work/cm3-inst/something/bin/bin, bin/pkg, bin/man. It seems that Tinderbox might be messing up the "update"? Maybe I setup these all up wrong myself but I don't think so. I'll see if they come back. I'm just now getting Tinderbox working almost whereas before I was never able to get far. I've gotten "lastok" builds through. I haven't seen tests run but maybe the current attempts will. Since I was using e.g. a new platform SPARC32_LINUX, I setup all the "installations" just by copying files around. The instructions require a 5.4.0 release to exist. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 20 23:39:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 23:39:58 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: <20090720233958.8y2yyvyqecgo0kk0@mail.elegosoft.com> Quoting Jay K : > How do I get tinderbox to run the tests? > > It looks like maybe BUILD_REL=lastok does not but letting BUILD_REL > default does. > > I'll fake up a 5.4 install with current files... > > Let it be known that "lastrel" builds might actually be "lastok" > builds. If you can tell which ones are mine.. Just edit cm3.build like I did on birch: do_tests() { # Enable tests on birch for non-release builds. # FIXME: Must be removed when we have a new release. #if [ "${BUILD_REL}" == "rel" ] ; then std_tests 2>&1 | tee ~/tmp/cm3-tests.log #fi } Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 20 23:44:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 20 Jul 2009 23:44:26 +0200 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: References: Message-ID: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Quoting Jay K : > On three machines now I've seen work/cm3-inst/something/bin/bin, > bin/pkg, bin/man. > It seems that Tinderbox might be messing up the "update"? Looks to me like a problem in shipping or in the cm3 config files... > Maybe I setup these all up wrong myself but I don't think so. > > I'll see if they come back. > > I'm just now getting Tinderbox working almost whereas before I was > never able to get far. > > I've gotten "lastok" builds through. I haven't seen tests run but > maybe the current attempts will. > > Since I was using e.g. a new platform SPARC32_LINUX, I setup all the > "installations" just by > > copying files around. The instructions require a 5.4.0 release to exist. You can just edit cm3.build as written in the last mail and then build lastok. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 01:49:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 20 Jul 2009 23:49:37 +0000 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> References: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Message-ID: > Looks to me like a problem in shipping or in the cm3 config files... Thanks, you're right, I'm missing: INSTALL_ROOT = (path() & SL & "..") in the first cm3.cfg. > You can just edit cm3.build as written in the last mail and then build > lastok. ok, thanks. I don't like having to edit the file, or read the file, just want to read the documenation. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 02:42:58 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 20 Jul 2009 20:42:58 -0400 Subject: [M3devel] do-cm3.cmd for Windows Message-ID: <4A64D69D.1E75.00D7.1@scires.com> I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP that operates based on the "scripts/PkgInfo.txt" file. I have a question about the format of the "scripts/PkgInfo.txt" file. Most of the lines in this file identify a package by name as the first entry on the line. A few of them also provide a relative path to this package. If the source tree is rooted at "sandbox\cm3", we have subfolders "m3-sys", "m3-games", etc. How do we know in which unique subfolder each package is located? For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" while, "netobj" is in "sandbox\cm3\m3-comm\netobj" Then we have in PkgInfo.txt lines like: "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman\kemacs" "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" I can see the need for the relative path for "paneman/kemacs", but "m3-games/badbricks" seems to break with the established pattern. Is this an error in the current PkgInfo.txt file? Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 03:56:38 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 18:56:38 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <4A64D69D.1E75.00D7.1@scires.com> References: <4A64D69D.1E75.00D7.1@scires.com> Message-ID: <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> do-pkg.cmd already does this doesn't it? It is looking for substring matches against paths or somesuch like the .sh code. Not actually package names. - Jay (phone) On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" wrote: > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > that operates based on the "scripts/PkgInfo.txt" file. > > I have a question about the format of the "scripts/PkgInfo.txt" file. > > Most of the lines in this file identify a package by name as the > first entry on the line. A few of them also provide a relative path > to this package. > > If the source tree is rooted at "sandbox\cm3", we have subfolders > "m3-sys", "m3-games", etc. > > How do we know in which unique subfolder each package is located? > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > Then we have in PkgInfo.txt lines like: > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > \kemacs" > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > I can see the need for the relative path for "paneman/kemacs", but > "m3-games/badbricks" seems to break with the established pattern. > Is this an error in the current PkgInfo.txt file? > > Regards, > Randy Coleburn From rcoleburn at scires.com Tue Jul 21 06:50:22 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 00:50:22 -0400 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> Message-ID: <4A651097.1E75.00D7.1@scires.com> Jay: I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3-*.cmd" scripts actually do. Some of the code is pretty complex and I decided it would take me longer to figure it out than to just write a new script. Anyway, you didn't answer my questions, so I've experimented to come up with something that seems to work for the current cases in PkgInfo.txt. I've uploaded a new file "do-cm3.cmd" that processes the "PkgInfo.txt" file based on my understanding of that file's format. I've tested it locally and it seems to work for me. This one .CMD file is meant to be an alternative to all of the various "do-pkg.cmd" and "do-cm3-*.cmd" files. Here are examples of how it could be called: cd "scripts\win" do-cm3 std buildship do-cm3 game clean buildship do-cm3 game realclean build ship do-cm3 comm depends do-cm3 all buildship There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use this file, simply comment-out this block of code or set CM3_DoneSetup=TRUE at the beginning of the block to prevent it from running. If anyone tries my new script, let me know if you experience any problems and I'll try to fix them. Finally, if I want to adapt my "do-cm3.cmd" script to also handle the work of "upgrade.cmd", I'm going to need someone to explain to me the compilation and shipping order for the upgrade process. Regards, Randy Coleburn >>> 7/20/2009 9:56 PM >>> do-pkg.cmd already does this doesn't it? It is looking for substring matches against paths or somesuch like the .sh code. Not actually package names. - Jay (phone) On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" wrote: > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > that operates based on the "scripts/PkgInfo.txt" file. > > I have a question about the format of the "scripts/PkgInfo.txt" file. > > Most of the lines in this file identify a package by name as the > first entry on the line. A few of them also provide a relative path > to this package. > > If the source tree is rooted at "sandbox\cm3", we have subfolders > "m3-sys", "m3-games", etc. > > How do we know in which unique subfolder each package is located? > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > Then we have in PkgInfo.txt lines like: > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > \kemacs" > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > I can see the need for the relative path for "paneman/kemacs", but > "m3-games/badbricks" seems to break with the established pattern. > Is this an error in the current PkgInfo.txt file? > > Regards, > Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 07:28:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 07:28:14 +0200 Subject: [M3devel] tinderbox confusing bin and root? In-Reply-To: References: <20090720234426.0fr5iifa4ggwww0w@mail.elegosoft.com> Message-ID: <20090721072814.5hso9gnezo84kssw@mail.elegosoft.com> Quoting Jay K : >> Looks to me like a problem in shipping or in the cm3 config files... > > Thanks, you're right, I'm missing: > > INSTALL_ROOT = (path() & SL & "..") > > in the first cm3.cfg. > >> You can just edit cm3.build as written in the last mail and then build >> lastok. > > > > ok, thanks. I don't like having to edit the file, or read the file, just want > > to read the documenation. > > Well, you have to edit the files anyway to enable the tinderbox communication. And it's no big deal to comment out three more lines ;-) Of course we could define more variables or options... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 07:08:39 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 22:08:39 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <4A651097.1E75.00D7.1@scires.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> Message-ID: <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py. - Jay (phone) On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" wrote: > Jay: > > I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- > *.cmd" scripts actually do. Some of the code is pretty complex and > I decided it would take me longer to figure it out than to just > write a new script. > > Anyway, you didn't answer my questions, so I've experimented to come > up with something that seems to work for the current cases in > PkgInfo.txt. > > I've uploaded a new file "do-cm3.cmd" that processes the > "PkgInfo.txt" file based on my understanding of that file's format. > I've tested it locally and it seems to work for me. > > This one .CMD file is meant to be an alternative to all of the > various "do-pkg.cmd" and "do-cm3-*.cmd" files. > > Here are examples of how it could be called: > cd "scripts\win" > do-cm3 std buildship > do-cm3 game clean buildship > do-cm3 game realclean build ship > do-cm3 comm depends > do-cm3 all buildship > > There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that > expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use > this file, simply comment-out this block of code or set > CM3_DoneSetup=TRUE at the beginning of the block to prevent it from > running. > > If anyone tries my new script, let me know if you experience any > problems and I'll try to fix them. > > Finally, if I want to adapt my "do-cm3.cmd" script to also handle > the work of "upgrade.cmd", I'm going to need someone to explain to > me the compilation and shipping order for the upgrade process. > > Regards, > Randy Coleburn > > >>> 7/20/2009 9:56 PM >>> > do-pkg.cmd already does this doesn't it? > It is looking for substring matches against paths or somesuch like > the .sh code. > Not actually package names. > > - Jay (phone) > > On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" > wrote: > > > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/XP > > that operates based on the "scripts/PkgInfo.txt" file. > > > > I have a question about the format of the "scripts/PkgInfo.txt" > file. > > > > Most of the lines in this file identify a package by name as the > > first entry on the line. A few of them also provide a relative path > > to this package. > > > > If the source tree is rooted at "sandbox\cm3", we have subfolders > > "m3-sys", "m3-games", etc. > > > > How do we know in which unique subfolder each package is located? > > > > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" > > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" > > > > Then we have in PkgInfo.txt lines like: > > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman > > \kemacs" > > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" > > > > I can see the need for the relative path for "paneman/kemacs", but > > "m3-games/badbricks" seems to break with the established pattern. > > Is this an error in the current PkgInfo.txt file? > > > > Regards, > > Randy Coleburn > From jay.krell at cornell.edu Tue Jul 21 08:26:42 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 20 Jul 2009 23:26:42 -0700 Subject: [M3devel] do-cm3.cmd for Windows In-Reply-To: <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> Message-ID: <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then clean and build in order from the bottom. You could say it starts after libm3 or at sysutils, but there is also import-libs. In future if released cm3 can build current m3core and libm3 then just build from the bottom and on up, nothing tricky. Thinking about this now I think we should have just done the trick once and then declared the resulting cm3 as the baseline, instead of this 'institutionalization' of the 'workaround' that seems to confuse everyone, and leaves compat hacks in to deal with older releases. I think we should abandon 5.4 as a base before this release so this can be cleaned up. - Jay (phone) On Jul 20, 2009, at 10:08 PM, jay.krell at cornell.edu wrote: > Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py. > > - Jay (phone) > > On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" > wrote: > >> Jay: >> >> I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- >> *.cmd" scripts actually do. Some of the code is pretty complex and >> I decided it would take me longer to figure it out than to just >> write a new script. >> >> Anyway, you didn't answer my questions, so I've experimented to >> come up with something that seems to work for the current cases in >> PkgInfo.txt. >> >> I've uploaded a new file "do-cm3.cmd" that processes the >> "PkgInfo.txt" file based on my understanding of that file's >> format. I've tested it locally and it seems to work for me. >> >> This one .CMD file is meant to be an alternative to all of the >> various "do-pkg.cmd" and "do-cm3-*.cmd" files. >> >> Here are examples of how it could be called: >> cd "scripts\win" >> do-cm3 std buildship >> do-cm3 game clean buildship >> do-cm3 game realclean build ship >> do-cm3 comm depends >> do-cm3 all buildship >> >> There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that >> expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use >> this file, simply comment-out this block of code or set >> CM3_DoneSetup=TRUE at the beginning of the block to prevent it from >> running. >> >> If anyone tries my new script, let me know if you experience any >> problems and I'll try to fix them. >> >> Finally, if I want to adapt my "do-cm3.cmd" script to also handle >> the work of "upgrade.cmd", I'm going to need someone to explain to >> me the compilation and shipping order for the upgrade process. >> >> Regards, >> Randy Coleburn >> >> >>> 7/20/2009 9:56 PM >>> >> do-pkg.cmd already does this doesn't it? >> It is looking for substring matches against paths or somesuch like >> the .sh code. >> Not actually package names. >> >> - Jay (phone) >> >> On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" >> wrote: >> >> > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/ >> XP >> > that operates based on the "scripts/PkgInfo.txt" file. >> > >> > I have a question about the format of the "scripts/PkgInfo.txt" >> file. >> > >> > Most of the lines in this file identify a package by name as the >> > first entry on the line. A few of them also provide a relative >> path >> > to this package. >> > >> > If the source tree is rooted at "sandbox\cm3", we have subfolders >> > "m3-sys", "m3-games", etc. >> > >> > How do we know in which unique subfolder each package is located? >> > >> > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc" >> > while, "netobj" is in "sandbox\cm3\m3-comm\netobj" >> > >> > Then we have in PkgInfo.txt lines like: >> > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman >> > \kemacs" >> > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks" >> > >> > I can see the need for the relative path for "paneman/kemacs", but >> > "m3-games/badbricks" seems to break with the established pattern. >> > Is this an error in the current PkgInfo.txt file? >> > >> > Regards, >> > Randy Coleburn >> > From rcoleburn at scires.com Tue Jul 21 09:26:56 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 03:26:56 -0400 Subject: [M3devel] status report on Windows XP Message-ID: <4A653548.1E75.00D7.1@scires.com> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 09:38:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 03:38:53 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <4A653815.1E75.00D7.1@scires.com> I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 09:58:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 07:58:27 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: > I've even tried it with the "examples" folder missing and it still works fine. and click the examples link? - Jay Date: Tue, 21 Jul 2009 03:26:56 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] status report on Windows XP This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 10:05:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 08:05:54 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: Bear in mind some features: do-pkg (via sysinfo) does a good job of finding compiler/linker You can copy that, but I also intend to move it into the config files if I can. Though not sure e.g. path/lib/include-search is easy there. And I don't want the config files every time to launch a bunch of processes to do the probing. Maybe move the logic to cm3 itself. Maybe. sets the version defines when building cm3, by reading the version file The python, .sh, and preexisting .cmd do that. You can copy the code out though. Is a little more easily extended -- no builtin list of package groups, but not a big deal. Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. Ditto for do-cm3-std.py wrapping do-pkg.py. The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, and then improved things by introducing pkginfo.txt. Some of the generalizations aren't useful. I'm going to remove the purported support for PM3 and M3 from pylib.py for example. My Python code is still missing a nifty feature that Olaf added to the .sh where you can pass extra parameters on to cm3. Yeah we do need to filter out more packages. The package list has grown since I last used the .cmd files and pylib.py has its own list, so I might not be building those packages on any platform. I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. .cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. Again you might want to try writing JScript. It is much more natural. It can be slow but you aren't likely to notice here. And it is very portable to Windows. You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 10:24:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 08:24:44 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: > Yeah we do need to filter out more packages. If you look for "FilterOnePackage" in pkginfo.cmd you can see this support. I'll see about moving it to the m3makefiles instead though. I'm not sure it deals with the slashes in some of the package paths either. Well..err..clearly not, but not hard to fix. Anyway, I'll see about the m3makefiles. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Tue, 21 Jul 2009 08:05:54 +0000 Subject: Re: [M3devel] status report on Windows XP Bear in mind some features: do-pkg (via sysinfo) does a good job of finding compiler/linker You can copy that, but I also intend to move it into the config files if I can. Though not sure e.g. path/lib/include-search is easy there. And I don't want the config files every time to launch a bunch of processes to do the probing. Maybe move the logic to cm3 itself. Maybe. sets the version defines when building cm3, by reading the version file The python, .sh, and preexisting .cmd do that. You can copy the code out though. Is a little more easily extended -- no builtin list of package groups, but not a big deal. Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. Ditto for do-cm3-std.py wrapping do-pkg.py. The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, and then improved things by introducing pkginfo.txt. Some of the generalizations aren't useful. I'm going to remove the purported support for PM3 and M3 from pylib.py for example. My Python code is still missing a nifty feature that Olaf added to the .sh where you can pass extra parameters on to cm3. Yeah we do need to filter out more packages. The package list has grown since I last used the .cmd files and pylib.py has its own list, so I might not be building those packages on any platform. I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. .cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. Again you might want to try writing JScript. It is much more natural. It can be slow but you aren't likely to notice here. And it is very portable to Windows. You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 10:45:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 10:45:25 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> Message-ID: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > clean and build in order from the bottom. You could say it starts after > libm3 or at sysutils, but there is also import-libs. In future if > released cm3 can build current m3core and libm3 then just build from > the bottom and on up, nothing tricky. Thinking about this now I think > we should have just done the trick once and then declared the resulting > cm3 as the baseline, instead of this 'institutionalization' of the > 'workaround' that seems to confuse everyone, and leaves compat hacks in > to deal with older releases. I think we should abandon 5.4 as a base > before this release so this can be cleaned up. Jay, there is a subtle dependency between the platforms that are contained in cm3 and m3core. You cannot compile a newer m3core with a compiler that doesn't support new platforms. At least I am not aware that this dependency has been removed, or has it? Please explain again in case I missed something. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 10:52:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 10:52:45 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653548.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> Quoting Randy Coleburn : > This report is for Windows XP Professional, Service Pack 3, using > Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft > .NET Framework Version 3.5 SP1. > > I've updated my local sandbox to be current with the CM3 CVS > repository at elego. I've performed a "upgrade.cmd" to upgrade my > cm3 compiler to the latest version. > > I kept running into problems with "scripts\win\do-cm3-std.CMD" > stopping short with an error message. > > So, I built my own "do-cm3.CMD" and used it to rebuild everything. > > Here are the packages that fail to build (I think most of these are > not supported currently on Windows): > m3-sys\m3cc > m3-libs\tcl > caltech-parser\term > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib\test We should exclude these packages from builds on Windows for the time being. I'm not sure why the caltech-parser is Unix-dependent, but we can fix that later. > m3-tools\pp Pretty printing shouldn't be Unix-dependent, too, at least I'd think so, but it's also no problem for the release. Nonetheless, coould you write two tickets in trac about failing compilation for the caltech-parser and pp on NT386? Just to make sure we won't forget about it... > I've also built tested CM3IDE and it seems to work fine on Windows. > I've even tried it with the "examples" folder missing and it still > works fine. So it's not reproducible? Or has anything been changed? > I'll try to check out how well some of the other packages run as > time permits. Fine. Thanks for the tests and the report, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 11:02:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 09:02:00 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: I fixed that bug at least in libm3. The dependency was easily removed and very painful when present. see: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 Is there more of it? I haven't see the error in a while. Coincidence? I can test it out.. - Jay > Date: Tue, 21 Jul 2009 10:45:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting jay.krell at cornell.edu: > > > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > > clean and build in order from the bottom. You could say it starts after > > libm3 or at sysutils, but there is also import-libs. In future if > > released cm3 can build current m3core and libm3 then just build from > > the bottom and on up, nothing tricky. Thinking about this now I think > > we should have just done the trick once and then declared the resulting > > cm3 as the baseline, instead of this 'institutionalization' of the > > 'workaround' that seems to confuse everyone, and leaves compat hacks in > > to deal with older releases. I think we should abandon 5.4 as a base > > before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 11:09:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 09:09:11 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: also: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/OSConfigPosix.m3.diff?r1=1.21;r2=1.22 a bunch of dead strings also removed.. There are references to the Compiler type in m3core. C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTDebug.m3(9): EOL = ARRAY Compiler.OS OF TEXT { "\n", "\r\n" }[ Compiler.ThisOS ]; C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RuntimeError.m3(16): self := LOOPHOLE (Compiler.ThisException(), RT0.ActivationPtr).exception; I don't think these are problems, but agreed it is a little fragile. The problem is presumably only present if Compiler.Platform or Compiler.ThisPlatform is referenced. The first use breaks of OS = {Win32, Posix} grows, but that is also trivially fixed. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Tue, 21 Jul 2009 09:02:00 +0000 Subject: Re: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows I fixed that bug at least in libm3. The dependency was easily removed and very painful when present. see: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 Is there more of it? I haven't see the error in a while. Coincidence? I can test it out.. - Jay > Date: Tue, 21 Jul 2009 10:45:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting jay.krell at cornell.edu: > > > Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then > > clean and build in order from the bottom. You could say it starts after > > libm3 or at sysutils, but there is also import-libs. In future if > > released cm3 can build current m3core and libm3 then just build from > > the bottom and on up, nothing tricky. Thinking about this now I think > > we should have just done the trick once and then declared the resulting > > cm3 as the baseline, instead of this 'institutionalization' of the > > 'workaround' that seems to confuse everyone, and leaves compat hacks in > > to deal with older releases. I think we should abandon 5.4 as a base > > before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 13:30:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 13:30:18 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Quoting Jay K : > I fixed that bug at least in libm3. The dependency was easily > removed and very painful when present. > > see: > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 And that was all? > Is there more of it? I don't know offhand. > I haven't see the error in a while. Coincidence? > > I can test it out.. Yes, please retest it, and if compilation works after addition of a new platform without complex boot upgrade, we'll forget about it. It would be great if that's really past! Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 21 13:43:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:43:18 +0000 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Message-ID: There was another file, C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\OSConfigPosix.m3 or such. and this hack was altered: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(505): IF SocketPosix_IsUltrixOrOSF.Value THEN it was already a hack, and it is still a hack, just not with the bad dependency any longer. Yes, I believe it is fixed. I can't reproduce the problem. I added a target to just C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\Compiler.tmpl which I believe is the only relevant thing in m3core and libm3. The other stuff in libm3 used to be relevant. Hey, /if/ I'm wrong, /and/ we can't fix it, we can go back to the old way. I do have more targets for after 5.8 hopefully. Fixing of the names might be via just adding new targets for example: I386_NT, I386_CYGWIN, I386_MINGW or I386_MINGNUWIN, I386_LINUX, I386_FREEBSD, I386_NETBSD, just not sure about SPARC_SOLARIS or SPARC32_SOLARIS and how to differentiate SOLgnu vs. SOLsun... and other "real" targets anyway, ALPHA_LINUX, ALPHA_*BSD.... Anecdotally I can tell you that even when I knew about and understood the problem, I still encountered the error a bunch, and would fix it. I don't recall seeing it in a while. - Jay > Date: Tue, 21 Jul 2009 13:30:18 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows > > Quoting Jay K : > > > I fixed that bug at least in libm3. The dependency was easily > > removed and very painful when present. > > > > see: > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 > > And that was all? > > > Is there more of it? > > I don't know offhand. > > > I haven't see the error in a while. Coincidence? > > > > I can test it out.. > > Yes, please retest it, and if compilation works after addition of > a new platform without complex boot upgrade, we'll forget about it. > > It would be great if that's really past! > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 13:49:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:49:21 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: These should all be ok now except for m3cc. Hopefully you can filter it out somehow. After the 5.8 release I'll split up the NT386 platforms into three platforms and then the m3cc/src/m3makefile can do the filtering naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but disallowing it for I386_NT). tcl has other problems imho, I disabled it for Win32. It is a massive clone of C headers from years ago and could easily be out of date. The right fix anyway is probably to add Tcl to SYSLIBS -- venturing on actually needing the config files to actually vary per user.. pp requires lex/yacc or flex/bison, and would give an error indicating so. Now it just does nothing if they are missing. caltech requires termios/cfmakeraw, I put in a do-nothing version of Win32 and fixed the Posix version to be safer, more portable, and more and less efficient. I don't know why it was disabling the garbage collector so I removed that. Was that termios.i3 actually portable? Are the structs of known size across all Posix systems and the constants constant? A better Win32 implementation probably isn't difficult. It'd be great if anyone could sign up and say they use this caltech parser stuff, including the terminal stuff it is doing (try removing the cfmakeraw call, notice a difference, and test the Win32 version and verify it doesn't work great..?) Actually I ran some of the executables there and got some usage statements and an array index out of bounds or such in some gui code.. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 13:50:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 11:50:27 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A653815.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: [truncated..no big deal...] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] status report on Windows XP Date: Tue, 21 Jul 2009 11:49:21 +0000 These should all be ok now except for m3cc. Hopefully you can filter it out somehow. After the 5.8 release I'll split up the NT386 platforms into three platforms and then the m3cc/src/m3makefile can do the filtering naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but disallowing it for I386_NT). tcl has other problems imho, I disabled it for Win32. It is a massive clone of C headers from years ago and could easily be out of date. The right fix anyway is probably to add Tcl to SYSLIBS -- venturing on actually needing the config files to actually vary per user.. pp requires lex/yacc or flex/bison, and would give an error indicating so. Now it just does nothing if they are missing. caltech requires termios/cfmakeraw, I put in a do-nothing version of Win32 and fixed the Posix version to be safer, more portable, and more and less efficient. I don't know why it was disabling the garbage collector so I removed that. Was that termios.i3 actually portable? Are the structs of known size across all Posix systems and the constants constant? A better Win32 implementation probably isn't difficult. It'd be great if anyone could sign up and say they use this caltech parser stuff, including the terminal stuff it is doing (try removing the cfmakeraw call, notice a difference, and test the Win32 version and verify it doesn't work great..?) Actually I ran some of the executables there and got some usage statements and an array index out of bounds or such in some gui code.. - Jay Date: Tue, 21 Jul 2009 03:38:53 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] status report on Windows XP I should restate that these are the packages where "cm3 -build" terminated with an errorlevel set. There are some other packages that do not build because their m3makefile is configured not to build for NT386 platforms, or for some other reason, e.g. X-Windows not available. Regards, Randy >>> "Randy Coleburn" 7/21/2009 3:26 AM >>> This report is for Windows XP Professional, Service Pack 3, using Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM, and Microsoft .NET Framework Version 3.5 SP1. I've updated my local sandbox to be current with the CM3 CVS repository at elego. I've performed a "upgrade.cmd" to upgrade my cm3 compiler to the latest version. I kept running into problems with "scripts\win\do-cm3-std.CMD" stopping short with an error message. So, I built my own "do-cm3.CMD" and used it to rebuild everything. Here are the packages that fail to build (I think most of these are not supported currently on Windows): m3-sys\m3cc m3-libs\tcl caltech-parser\term caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\parserlib\klexlib caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib\test m3-tools\pp I've also built tested CM3IDE and it seems to work fine on Windows. I've even tried it with the "examples" folder missing and it still works fine. I'll try to check out how well some of the other packages run as time permits. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 21 14:25:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 12:25:38 +0000 Subject: [M3devel] libodbc may conflict with libodbc.... Message-ID: http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html#tr_m3-sys-cm3 I see that our libodbc.a may conflict with the "real" one. We should probably rename to libm3odbc or such. - Jay From jay.krell at cornell.edu Tue Jul 21 14:37:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 12:37:15 +0000 Subject: [M3devel] config file issue Message-ID: Olaf..sorry, this movement to the config directory seemed very easy at the time..and it is still not quite working. http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/cm3cfg.common", line 170: quake runtime error: undefined variable: ROOT That's probably an old version, where the use isn't guarded with if defined. upgrade.sh: if [ ! -d "${INSTALLROOT}/bin/config" ]; then echo "create new config sub directory ${INSTALLROOT}/bin/config" cp_config_files fi Why the guard with ! -d? How about just always do it? There are other paths...I don't understand..how about just always do it? - Jay From wagner at elegosoft.com Tue Jul 21 16:41:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 16:41:01 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> <20090721133018.4n4zz5zeqwog4o40@mail.elegosoft.com> Message-ID: <20090721164101.jjmx0bbk04cc840g@mail.elegosoft.com> Great! Thanks, Olaf Quoting Jay K : > There was another file, > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\OSConfigPosix.m3 or such. > and this hack was altered: > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(505): IF > SocketPosix_IsUltrixOrOSF.Value THEN > > > it was already a hack, and it is still a hack, just not with the bad > dependency any longer. > > > > Yes, I believe it is fixed. > > I can't reproduce the problem. > > I added a target to just > C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\Compiler.tmpl > > which I believe is the only relevant thing in m3core and libm3. > > The other stuff in libm3 used to be relevant. > > > > Hey, /if/ I'm wrong, /and/ we can't fix it, we can go back to the old way. > > I do have more targets for after 5.8 hopefully. > > Fixing of the names might be via just adding new targets for > example: I386_NT, I386_CYGWIN, I386_MINGW or I386_MINGNUWIN, > I386_LINUX, I386_FREEBSD, I386_NETBSD, just not sure about > SPARC_SOLARIS or SPARC32_SOLARIS and how to differentiate SOLgnu vs. > SOLsun... and other "real" targets anyway, ALPHA_LINUX, > ALPHA_*BSD.... > > > > > > Anecdotally I can tell you that even when I knew about and > understood the problem, I still encountered the error a bunch, and > would fix it. I don't recall seeing it in a while. > > > > > > - Jay > >> Date: Tue, 21 Jul 2009 13:30:18 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows >> >> Quoting Jay K : >> >> > I fixed that bug at least in libm3. The dependency was easily >> > removed and very painful when present. >> > >> > see: >> > >> > >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.8;r2=1.9 >> > >> > >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/m3makefile.diff?r1=1.10;r2=1.11 >> >> And that was all? >> >> > Is there more of it? >> >> I don't know offhand. >> >> > I haven't see the error in a while. Coincidence? >> > >> > I can test it out.. >> >> Yes, please retest it, and if compilation works after addition of >> a new platform without complex boot upgrade, we'll forget about it. >> >> It would be great if that's really past! >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcolebur at scires.com Tue Jul 21 16:42:04 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 10:42:04 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> Message-ID: <4A659B7C.1E75.00D7.1@scires.com> yes, I can click the link and cm3ide reports that the examples are not available. --Randy >>> Jay K 7/21/2009 3:58 AM >>> > I've even tried it with the "examples" folder missing and it still works fine. and click the examples link? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From wagner at elegosoft.com Tue Jul 21 16:43:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 16:43:37 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: <20090721164337.j7bbvffiuc08c44k@mail.elegosoft.com> Quoting Jay K : > These should all be ok now except for m3cc. > > Hopefully you can filter it out somehow. > > After the 5.8 release I'll split up the NT386 platforms into three > platforms and then the m3cc/src/m3makefile can do the filtering > naturally (allowing it for I386_CYGWIN and I386_MINGW/MINGNUWIN but > disallowing it for I386_NT). > > tcl has other problems imho, I disabled it for Win32. > > It is a massive clone of C headers from years ago and could easily > be out of date. > > The right fix anyway is probably to add Tcl to SYSLIBS -- venturing > on actually needing the config files to actually vary per user.. Is really anybody using TCL these days? Probably the right thing to do is just remove it ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Jul 21 17:02:28 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:02:28 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> Message-ID: <4A65A009.1E75.00D7.1@scires.com> >>> Jay K 7/21/2009 4:05 AM >>> >Bear in mind some features:> > do-pkg (via sysinfo) does a good job of finding compiler/linker > You can copy that, but I also intend to move it into the config files if I can. > Though not sure e.g. path/lib/include-search is easy there. > And I don't want the config files every time to launch a bunch of processes to do the probing. > Maybe move the logic to cm3 itself. Maybe. My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > sets the version defines when building cm3, by reading the version file > The python, .sh, and preexisting .cmd do that. You can copy the code out though. I thought the version information was built into the compiler? >Is a little more easily extended -- no builtin list of package groups, but not a big deal. >Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >Ditto for do-cm3-std.py wrapping do-pkg.py. This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. >The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >and then improved things by introducing pkginfo.txt. My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. >Some of the generalizations aren't useful. >I'm going to remove the purported support for PM3 and M3 from pylib.py for example. >My Python code is still missing a nifty feature that Olaf added to the .sh where you can >pass extra parameters on to cm3. My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. >Yeah we do need to filter out more packages. >The package list has grown since I last used the .cmd files and pylib.py has its own list, >so I might not be building those packages on any platform. >I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. >.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >Again you might want to try writing JScript. It is much more natural. It can be slow >but you aren't likely to notice here. And it is very portable to Windows. >You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 17:10:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:10:41 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> References: <4A653548.1E75.00D7.1@scires.com> <20090721105245.chjncca96ogg8o44@mail.elegosoft.com> Message-ID: <4A65A1F7.1E75.00D7.1@scires.com> >>> Olaf Wagner 7/21/2009 4:52 AM >>> >Nonetheless, coould you write two tickets in trac about failing >compilation for the caltech-parser and pp on NT386? >Just to make sure we won't forget about it... I can do this, but I will need an account on trac I think in order to do it. Can you set this up for me? --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 17:17:24 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 11:17:24 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090721095537.18D8ECC806@birch.elegosoft.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> Message-ID: <4A65A389.1E75.00D7.1@scires.com> Granted, I see that Term.m3 is an UNSAFE module, so that by definition means it is not portable. Why though do we want to replace it by nasty C code where non-portable stuff can be easily hidden? This is Modula-3. Why not fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 cents.) --Randy >>> Jay Krell 7/21/2009 11:55 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/07/21 11:55:36 Added files: cm3/caltech-parser/term/src/: TermC.c Log message: initial copy of dangerous non portable Term.m3 to rewrite portably and have it do nothing silently on Win32 which should suffice, or if not, can probably be done better, specifically the MakeRaw function CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 21 17:18:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:18:49 +0200 Subject: [M3devel] libodbc may conflict with libodbc.... In-Reply-To: References: Message-ID: <20090721171849.52nhb28p8kocwswo@mail.elegosoft.com> Quoting Jay K : > http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-AMD64_LINUX.html#tr_m3-sys-cm3 > > I see that our libodbc.a may conflict with the "real" one. > We should probably rename to libm3odbc or such. Yes, pelase do. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 17:26:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:26:14 +0200 Subject: [M3devel] config file issue In-Reply-To: References: Message-ID: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> Quoting Jay K : > Olaf..sorry, this movement to the config directory seemed very easy > at the time..and it is still not quite working. > > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 > > > "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/cm3cfg.common", line > 170: quake runtime error: undefined variable: ROOT > > > That's probably an old version, where the use isn't guarded with if defined. > > upgrade.sh: > > if [ ! -d "${INSTALLROOT}/bin/config" ]; then > echo "create new config sub directory ${INSTALLROOT}/bin/config" > cp_config_files > fi > > > Why the guard with ! -d? > How about just always do it? > > There are other paths...I don't understand..how about just always do it? The original idea was to update config files only if the upgrade failed otherwise. That was to preserve any adaptions the end user might have made. To do it right in a real upgrade would require an interactive merge. I've got no problem with forcing the upgrade every time but keeping a backup. Of course, the user will immediately overwrite that with just repeating the command, if we don't version the backup... Please also consider that most users will have the single cm3.cfg which contains everything, while yours just delegates... So I'd vote for providing a backup with a timestamp and then forcing everything to use the new files. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jul 21 17:42:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 17:42:16 +0200 Subject: [M3devel] CM3 Trac access, was: Re: status report on Windows XP Message-ID: <20090721174216.e9wm4hax5sgkkcog@mail.elegosoft.com> Quoting Randy Coleburn : >>>> Olaf Wagner 7/21/2009 4:52 AM >>> >> Nonetheless, coould you write two tickets in trac about failing >> compilation for the caltech-parser and pp on NT386? >> Just to make sure we won't forget about it... > I can do this, but I will need an account on trac I think in order > to do it. Can you set this up for me? Any user should be able to create a new ticket in trac; at least that's how it should be. The link has been on our web pages for over a year; actually nobody has written a ticket, as far as I know ;-) But there were no complaints, too. There are only some old reports migrated grom GNATS. Let me know if it works without password; I'll setup an account for you nonetheless, but can do that only later from home, as the GUI admin function is broken. If anybody would like access, let me know now so I can do it in a batch... Olaf From hosking at cs.purdue.edu Tue Jul 21 18:03:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 12:03:35 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A65A389.1E75.00D7.1@scires.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> Message-ID: <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Hear, hear! Sent from my iPhone On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" wrote: > Granted, I see that Term.m3 is an UNSAFE module, so that by > definition means it is not portable. > Why though do we want to replace it by nasty C code where non- > portable stuff can be easily hidden? This is Modula-3. Why not fix > the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 cents.) > --Randy > > >>> Jay Krell 7/21/2009 11:55 AM >>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/07/21 11:55:36 > > Added files: > cm3/caltech-parser/term/src/: TermC.c > > Log message: > initial copy of dangerous non portable Term.m3 to rewrite portably > and have it do nothing silently on Win32 which should suffice, or if > not, can probably be done better, specifically the MakeRaw function > > From wagner at elegosoft.com Tue Jul 21 18:10:02 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 18:10:02 +0200 Subject: [M3devel] CM3 Continuous Integration with Hudson Message-ID: <20090721181002.7gak37gaaogwg8k8@mail.elegosoft.com> While in preparation for the pending release the target platforms in our tinderbox have grown significantly (though many are still red), I've set up some initial build and test jobs on a new system, which I'd like to replace Tinderbox gradually with during the next weeks or months. Have a look at http://hudson.modula3.com:8080/view/cm3/ Hudson is much more flexible and easier to use than Tinderbox. It can be completely configured and administered via HTTP, including upgrade and restart, which is a big plus at least for me currently (closed network except for HTTP). We can reuse most of the existing scripts, just need to change and adapt some settings. And convert our test results to JUnit XML format, but that's easy, too. Here are some of the advantages I see: o easy setup and configuration o easy online administration o very flexible setup of arbitrary jobs o default integration of CVS and Subversion version control systems, plug-ins for many more o easy integration of HTML and other documents see http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-FreeBSD4/ for an example o continuous integration via CVS polling working out of the box see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/changes and http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/scmPollLog/ o version control integration working out of the box: see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/37/changes#detail2 and http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile?r1=1.51&r2=1.52 o integrated history and trend reports: see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/buildTimeTrend (needs JUnit format for test result evaluation, not done yet) o HTTP access to the complete workspace see http://hudson.modula3.com:8080/view/cm3/job/cm3-lastok-build-AMD64_LINUX/ws/cm3/ o job report feeds for browser integration see http://hudson.modula3.com:8080/view/cm3/rssFailed o easy configuration backup, migration and transfer, as everything is stored in plain XML files And here are some disadvantages: o more heavyweight, needs more cpu and memory o needs slave installation on every build platform o needs ssh access for slave control, but allows publishing of job results from independent servers (not tested yet) o is written in Java and not Modula-3 :-) I've setup birch as master which also runs jobs for the AMD64_LINUX target platform, and my home computer as a slave server for FreeBSD. If anybody wants access to view the configuration details or try something him/herself, just let me know and I'll set up an account. I also plan to setup actual installation tests before the release. Have fun, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Jul 21 18:19:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 12:19:12 -0400 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: I think Jay already removed the dependency. Yes? Sent from my iPhone On Jul 21, 2009, at 4:45 AM, Olaf Wagner wrote: > Quoting jay.krell at cornell.edu: > >> Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then >> clean and build in order from the bottom. You could say it starts >> after >> libm3 or at sysutils, but there is also import-libs. In future if >> released cm3 can build current m3core and libm3 then just build from >> the bottom and on up, nothing tricky. Thinking about this now I think >> we should have just done the trick once and then declared the >> resulting >> cm3 as the baseline, instead of this 'institutionalization' of the >> 'workaround' that seems to confuse everyone, and leaves compat >> hacks in >> to deal with older releases. I think we should abandon 5.4 as a base >> before this release so this can be cleaned up. > > Jay, there is a subtle dependency between the platforms that are > contained in cm3 and m3core. You cannot compile a newer m3core with > a compiler that doesn't support new platforms. At least I am not aware > that this dependency has been removed, or has it? > > Please explain again in case I missed something. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Jul 21 19:53:10 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 21 Jul 2009 10:53:10 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: I might have left it able to be called safe. Honestly I look more for human verifiable safety and correctness and it lacked those before and now does not. If that coincides with machine verifable safety, great. Either way you need C here for correctness and safety. It isn't 'nasty'. Not using C here would be nasty. I think you have it backwards. UNLESS the sizes and constants here are well known but reading docs quickly I didn't see that. Unsafe does not imply not portable. - Jay (phone) On Jul 21, 2009, at 9:03 AM, Tony Hosking wrote: > Hear, hear! > > > Sent from my iPhone > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > wrote: > >> Granted, I see that Term.m3 is an UNSAFE module, so that by >> definition means it is not portable. >> Why though do we want to replace it by nasty C code where non- >> portable stuff can be easily hidden? This is Modula-3. Why not >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >> cents.) >> --Randy >> >> >>> Jay Krell 7/21/2009 11:55 AM >>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/07/21 11:55:36 >> >> Added files: >> cm3/caltech-parser/term/src/: TermC.c >> >> Log message: >> initial copy of dangerous non portable Term.m3 to rewrite portably >> and have it do nothing silently on Win32 which should suffice, or >> if not, can probably be done better, specifically the MakeRaw >> function >> >> > From hosking at cs.purdue.edu Tue Jul 21 20:25:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 14:25:44 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> I assume the argument here is the same as for the POSIX interfaces. Sent from my iPhone On Jul 21, 2009, at 1:53 PM, jay.krell at cornell.edu wrote: > I might have left it able to be called safe. Honestly I look more > for human verifiable safety and correctness and it lacked those > before and now does not. If that coincides with machine verifable > safety, great. Either way you need C here for correctness and > safety. It isn't 'nasty'. Not using C here would be nasty. I think > you have it backwards. UNLESS the sizes and constants here are well > known but reading docs quickly I didn't see that. Unsafe does not > imply not portable. > > - Jay (phone) > > On Jul 21, 2009, at 9:03 AM, Tony Hosking > wrote: > >> Hear, hear! >> >> >> Sent from my iPhone >> >> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >> wrote: >> >>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>> definition means it is not portable. >>> Why though do we want to replace it by nasty C code where non- >>> portable stuff can be easily hidden? This is Modula-3. Why not >>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>> cents.) >>> --Randy >>> >>> >>> Jay Krell 7/21/2009 11:55 AM >>> >>> CVSROOT:/usr/cvs >>> Changes by:jkrell at birch.09/07/21 11:55:36 >>> >>> Added files: >>> cm3/caltech-parser/term/src/: TermC.c >>> >>> Log message: >>> initial copy of dangerous non portable Term.m3 to rewrite portably >>> and have it do nothing silently on Win32 which should suffice, or >>> if not, can probably be done better, specifically the MakeRaw >>> function >>> >>> >> From jay.krell at cornell.edu Tue Jul 21 20:24:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 21 Jul 2009 11:24:05 -0700 Subject: [M3devel] config file issue In-Reply-To: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> References: <20090721172614.54npx2wiskcskks8@mail.elegosoft.com> Message-ID: <94281F12-A8E5-4380-BE59-9C7145546679@hotmail.com> Agreed backup and always update. I don't want to consider merging. These are more code than data, but a mix. (code is data...the CPU is an interpreter...) I would like to aim for not needing user edits but that may be impossible to achieve. - Jay (phone) On Jul 21, 2009, at 8:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> Olaf..sorry, this movement to the config directory seemed very >> easy at the time..and it is still not quite working. >> >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248139749.31541 >> >> >> "/home/m3/work/cm3-inst/birch.elegosoft.com/current/bin/ >> cm3cfg.common", line 170: quake runtime error: undefined variable: >> ROOT >> >> >> That's probably an old version, where the use isn't guarded with if >> defined. >> >> upgrade.sh: >> >> if [ ! -d "${INSTALLROOT}/bin/config" ]; then >> echo "create new config sub directory ${INSTALLROOT}/bin/config" >> cp_config_files >> fi >> >> >> Why the guard with ! -d? >> How about just always do it? >> >> There are other paths...I don't understand..how about just always >> do it? > > The original idea was to update config files only if the upgrade > failed otherwise. That was to preserve any adaptions the end user > might have made. > > To do it right in a real upgrade would require an interactive merge. > I've got no problem with forcing the upgrade every time but keeping > a backup. Of course, the user will immediately overwrite that with > just repeating the command, if we don't version the backup... > > Please also consider that most users will have the single cm3.cfg > which contains everything, while yours just delegates... > > So I'd vote for providing a backup with a timestamp and then forcing > everything to use the new files. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From wagner at elegosoft.com Tue Jul 21 23:19:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Jul 2009 23:19:54 +0200 Subject: [M3devel] Upgrade dependencies, was: Re: do-cm3.cmd for Windows In-Reply-To: References: <4A64D69D.1E75.00D7.1@scires.com> <555BE52B-42C7-404D-B4B0-FAC5DAD11AFB@hotmail.com> <4A651097.1E75.00D7.1@scires.com> <7CCA2536-8C87-4813-894B-AA2D6911346B@hotmail.com> <65D19D0E-C155-489E-A6F5-C49BD532A3B9@hotmail.com> <20090721104525.864n6921kw8gggoc@mail.elegosoft.com> Message-ID: <20090721231954.c54oomrbwwcc48cc@mail.elegosoft.com> Quoting Tony Hosking : > I think Jay already removed the dependency. Yes? Seems he did, though I must have missed it :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Jul 21 23:53:31 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 17:53:31 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> Message-ID: <4A66005F.1E75.00D7.1@scires.com> Jay: I guess this topic is just a pet peeve of mine. We tout Modula-3 as a systems programming language and that it has all these great features that make it superior to languages that lack them, yet when we "don't practice what we preach" and use another language it weakens the argument. IMO, using C instead of Modula-3 is kind of like saying that we love baseball, but we have to use soccer to play baseball the right way. It just doesn't add up. I think we should always use Modula-3 in developing and enhancing the CM3 system. I must also disagree with you and state that for a TRUE Modula-3 fan, C is indeed "nasty." All that said, I haven't looked at the code in question here. I simply commented on the idea of replacing M3 code with C code. Regards, Randy >>> 7/21/2009 1:53 PM >>> I might have left it able to be called safe. Honestly I look more for human verifiable safety and correctness and it lacked those before and now does not. If that coincides with machine verifable safety, great. Either way you need C here for correctness and safety. It isn't 'nasty'. Not using C here would be nasty. I think you have it backwards. UNLESS the sizes and constants here are well known but reading docs quickly I didn't see that. Unsafe does not imply not portable. - Jay (phone) On Jul 21, 2009, at 9:03 AM, Tony Hosking wrote: > Hear, hear! > > > Sent from my iPhone > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > wrote: > >> Granted, I see that Term.m3 is an UNSAFE module, so that by >> definition means it is not portable. >> Why though do we want to replace it by nasty C code where non- >> portable stuff can be easily hidden? This is Modula-3. Why not >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >> cents.) >> --Randy >> >> >>> Jay Krell 7/21/2009 11:55 AM >>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/07/21 11:55:36 >> >> Added files: >> cm3/caltech-parser/term/src/: TermC.c >> >> Log message: >> initial copy of dangerous non portable Term.m3 to rewrite portably >> and have it do nothing silently on Win32 which should suffice, or >> if not, can probably be done better, specifically the MakeRaw >> function >> >> > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 21 23:59:47 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Jul 2009 17:59:47 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> Message-ID: <4A6601D6.1E75.00D7.1@scires.com> Jay, Glad to hear the PkgInfo.txt is viable and being maintained. Right now, I just don't have the time and motivation to learn jscript. I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine. The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks. Regards, Randy >>> 7/21/2009 2:11 PM >>> Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform. The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it. You do have jscript installed and it is pretty easy to read and learn. pkginfo.txt is important and maintained, yes. I need to switch the python to it. Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is. Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate. - Jay (phone) On Jul 21, 2009, at 8:02 AM, "Randy Coleburn" wrote: >>> Jay K 7/21/2009 4:05 AM >>> >Bear in mind some features:> > do-pkg (via sysinfo) does a good job of finding compiler/linker > You can copy that, but I also intend to move it into the config files if I can. > Though not sure e.g. path/lib/include-search is easy there. > And I don't want the config files every time to launch a bunch of processes to do the probing. > Maybe move the logic to cm3 itself. Maybe. My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > sets the version defines when building cm3, by reading the version file > The python, .sh, and preexisting .cmd do that. You can copy the code out though. I thought the version information was built into the compiler? >Is a little more easily extended -- no builtin list of package groups, but not a big deal. >Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >Ditto for do-cm3-std.py wrapping do-pkg.py. This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. >The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >and then improved things by introducing pkginfo.txt. My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. >Some of the generalizations aren't useful. >I'm going to remove the purported support for PM3 and M3 from pylib.py for example. >My Python code is still missing a nifty feature that Olaf added to the .sh where you can >pass extra parameters on to cm3. My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. >Yeah we do need to filter out more packages. >The package list has grown since I last used the .cmd files and pylib.py has its own list, >so I might not be building those packages on any platform. >I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. >.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >Again you might want to try writing JScript. It is much more natural. It can be slow >but you aren't likely to notice here. And it is very portable to Windows. >You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 22 00:37:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 22:37:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <464E7CCE-598E-428D-A233-953B421D6474@cs.purdue.edu> Message-ID: Correct. Unless this stuff is "well known" -- like the chmod values -- the code was wrong and/or highly platform specific, yet blithely did the same thing for all platforms. struct termio ws declared as merely an array of 500 char. Just an arbitrary size hoped to be large enough? Or known to be surely large enough? Or even exactly the right size? There was also a race condition in the initialization, typical, though arguably there still is. "Look at the code, not just checkin comments or the file extensions" I like to think to advise people. Except for .sh and .cmd, that I can indict just by extension. :) As I understand, when writing C code to interface to Modula-3, one has to really think about it before marking the interface as safe. For example, the C code I provided trusts the pointers it is given. So it is probably not safe. I would probably need to check the struct termios I get and compare them to the two known ones and only dereference them if it is one of them. NULL could also be deemed ok, as long as I silently did nothing with it, no dereference. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Tue, 21 Jul 2009 14:25:44 -0400 > CC: rcoleburn at scires.com; m3devel at elegosoft.com > > I assume the argument here is the same as for the POSIX interfaces. > > Sent from my iPhone > > On Jul 21, 2009, at 1:53 PM, jay.krell at cornell.edu wrote: > >> I might have left it able to be called safe. Honestly I look more >> for human verifiable safety and correctness and it lacked those >> before and now does not. If that coincides with machine verifable >> safety, great. Either way you need C here for correctness and >> safety. It isn't 'nasty'. Not using C here would be nasty. I think >> you have it backwards. UNLESS the sizes and constants here are well >> known but reading docs quickly I didn't see that. Unsafe does not >> imply not portable. >> >> - Jay (phone) >> >> On Jul 21, 2009, at 9:03 AM, Tony Hosking >> wrote: >> >>> Hear, hear! >>> >>> >>> Sent from my iPhone >>> >>> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >>> wrote: >>> >>>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>>> definition means it is not portable. >>>> Why though do we want to replace it by nasty C code where non- >>>> portable stuff can be easily hidden? This is Modula-3. Why not >>>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>>> cents.) >>>> --Randy >>>> >>>>>>> Jay Krell 7/21/2009 11:55 AM>>> >>>> CVSROOT:/usr/cvs >>>> Changes by:jkrell at birch.09/07/21 11:55:36 >>>> >>>> Added files: >>>> cm3/caltech-parser/term/src/: TermC.c >>>> >>>> Log message: >>>> initial copy of dangerous non portable Term.m3 to rewrite portably >>>> and have it do nothing silently on Win32 which should suffice, or >>>> if not, can probably be done better, specifically the MakeRaw >>>> function >>>> >>>> >>> From jay.krell at cornell.edu Wed Jul 22 00:39:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Jul 2009 22:39:34 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A6601D6.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> Message-ID: I use the Python all the time on various platforms. It works. The .cmds I wrote I rarely use, and then, only on Windows. I thought your list of failures would be down to just m3cc. What are they? - Jay ________________________________ > Date: Tue, 21 Jul 2009 17:59:47 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] status report on Windows XP > > > > > > > > Jay, > > > > Glad to hear the PkgInfo.txt is viable and being maintained. > > > > Right now, I just don't have the time and motivation to learn jscript. > > > > I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine. > > > > The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks. > > > > Regards, > > Randy > >>>> 7/21/2009 2:11 PM>>> > > Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform. > > > > The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it. > > > > You do have jscript installed and it is pretty easy to read and learn. > > > > pkginfo.txt is important and maintained, yes. > > I need to switch the python to it. > > > > Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is. > > > > Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate. > > > > - Jay (phone) > > > On Jul 21, 2009, at 8:02 AM, "Randy Coleburn"> wrote: > > > > > >>>> Jay K> 7/21/2009 4:05 AM>>> >>Bear in mind some features:> >> do-pkg (via sysinfo) does a good job of finding compiler/linker >> You can copy that, but I also intend to move it into the config files if I can. >> Though not sure e.g. path/lib/include-search is easy there. >> And I don't want the config files every time to launch a bunch of processes to do the probing. >> Maybe move the logic to cm3 itself. Maybe. > My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session. > > >> sets the version defines when building cm3, by reading the version file >> The python, .sh, and preexisting .cmd do that. You can copy the code out though. > I thought the version information was built into the compiler? > > >>Is a little more easily extended -- no builtin list of package groups, but not a big deal. >>Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd. >>Ditto for do-cm3-std.py wrapping do-pkg.py. > This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script. > > >>The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully, >>and then improved things by introducing pkginfo.txt. > My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date. > > >>Some of the generalizations aren't useful. >>I'm going to remove the purported support for PM3 and M3 from pylib.py for example. > >>My Python code is still missing a nifty feature that Olaf added to the .sh where you can >>pass extra parameters on to cm3. > My script allows you to pass multiple mode arguments to CM3 in the order you want them performed. > > >>Yeah we do need to filter out more packages. >>The package list has grown since I last used the .cmd files and pylib.py has its own list, >>so I might not be building those packages on any platform. >>I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd. > >>.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem. >>Again you might want to try writing JScript. It is much more natural. It can be slow >>but you aren't likely to notice here. And it is very portable to Windows. >>You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js. > Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy > > From hosking at cs.purdue.edu Wed Jul 22 02:19:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Jul 2009 20:19:02 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A66005F.1E75.00D7.1@scires.com> References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: I generally agree, but in this case we are probably dependent on a large number of C header files on the various different targets. Jay's efforts have reduced the burned of cloning C header files into Modula-3 interfaces. It is a fine line to tread though, and I think it is important to resist gratuitous rewrites into C code. In this case, I haven't had the chance to look at the code for Term.m3 and understand what is being attempted. On 21 Jul 2009, at 17:53, Randy Coleburn wrote: > Jay: > > I guess this topic is just a pet peeve of mine. > We tout Modula-3 as a systems programming language and that it has > all these great features that make it superior to languages that > lack them, yet when we "don't practice what we preach" and use > another language it weakens the argument. > > IMO, using C instead of Modula-3 is kind of like saying that we love > baseball, but we have to use soccer to play baseball the right way. > It just doesn't add up. > > I think we should always use Modula-3 in developing and enhancing > the CM3 system. > > I must also disagree with you and state that for a TRUE Modula-3 > fan, C is indeed "nasty." > > All that said, I haven't looked at the code in question here. I > simply commented on the idea of replacing M3 code with C code. > > Regards, > Randy > > >>> 7/21/2009 1:53 PM >>> > I might have left it able to be called safe. Honestly I look more for > human verifiable safety and correctness and it lacked those before and > now does not. If that coincides with machine verifable safety, great. > Either way you need C here for correctness and safety. It isn't > 'nasty'. Not using C here would be nasty. I think you have it > backwards. UNLESS the sizes and constants here are well known but > reading docs quickly I didn't see that. Unsafe does not imply not > portable. > > - Jay (phone) > > On Jul 21, 2009, at 9:03 AM, Tony Hosking > wrote: > > > Hear, hear! > > > > > > Sent from my iPhone > > > > On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" > > wrote: > > > >> Granted, I see that Term.m3 is an UNSAFE module, so that by > >> definition means it is not portable. > >> Why though do we want to replace it by nasty C code where non- > >> portable stuff can be easily hidden? This is Modula-3. Why not > >> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 > >> cents.) > >> --Randy > >> > >> >>> Jay Krell 7/21/2009 11:55 AM >>> > >> CVSROOT:/usr/cvs > >> Changes by:jkrell at birch.09/07/21 11:55:36 > >> > >> Added files: > >> cm3/caltech-parser/term/src/: TermC.c > >> > >> Log message: > >> initial copy of dangerous non portable Term.m3 to rewrite portably > >> and have it do nothing silently on Win32 which should suffice, or > >> if not, can probably be done better, specifically the MakeRaw > >> function > >> > >> > > > From jay.krell at cornell.edu Wed Jul 22 03:22:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 01:22:55 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: Until the kernels, libc, X-Windows, etc. are written in Modula-3, or come with Modula-3 *.i3 files provided by their maintainers, or perhaps completely stop changing, or perhaps we drop support for all but one target, all of which I predict to be never, it behooves us /significantly/ to interoperate with them via C. Otherwise you trade an impractical purist notion of using Modula-3 for portability and safety. The system is now tremendously more portable and safe with the replacement of a bunch of Modula-3 with far less portable clean safe C. It is true there is an extra layer when things are done this way, sometimes even extra copying. But it is worth it. Heck, it makes things more debuggable too because C tends to be more debuggable by gdb. Besides: The compiler front end is written in Modula-3. The garbage collector is written in Modula-3. The NT386 backend is written in Modula-3, and we should adapt that to all x86 targets. The compiler back-end is a //huge// piece of C (and M4, and Make, and Bourne shell...) The untraced heap is implemented in C. The "build scripts" are written in Bourne shell, Python, Cmd. They interact with a server written in at least Perl and C. You don't need the entire system to be in Modula-3 to prove that it is a "systems" language. You will never get there. Yes, I know people write web servers in other languages, including that cm3ide is essentially a web server written in Modula-3, but still, you won't get there. We should perhaps consider using the web server underpinnings of cm3ide to run modula3.elegosoft.com. Really. If it is close to already having the required functionality. We can actually have a bit more Modula-3 and less C. For example we could have our own untraced heap. We could implement Cstring.i3 ourselves in Modula-3. Besides all that, I've been using C a lot lately. I believe is far more tractable than most people think. Modula-3's safety and esp. its syntax get in my way. It isn't bad as, say, Java, but.. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Tue, 21 Jul 2009 20:19:02 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I generally agree, but in this case we are probably dependent on a > large number of C header files on the various different targets. > Jay's efforts have reduced the burned of cloning C header files into > Modula-3 interfaces. It is a fine line to tread though, and I think > it is important to resist gratuitous rewrites into C code. In this > case, I haven't had the chance to look at the code for Term.m3 and > understand what is being attempted. > > > On 21 Jul 2009, at 17:53, Randy Coleburn wrote: > >> Jay: >> >> I guess this topic is just a pet peeve of mine. >> We tout Modula-3 as a systems programming language and that it has >> all these great features that make it superior to languages that >> lack them, yet when we "don't practice what we preach" and use >> another language it weakens the argument. >> >> IMO, using C instead of Modula-3 is kind of like saying that we love >> baseball, but we have to use soccer to play baseball the right way. >> It just doesn't add up. >> >> I think we should always use Modula-3 in developing and enhancing >> the CM3 system. >> >> I must also disagree with you and state that for a TRUE Modula-3 >> fan, C is indeed "nasty." >> >> All that said, I haven't looked at the code in question here. I >> simply commented on the idea of replacing M3 code with C code. >> >> Regards, >> Randy >> >>>>> 7/21/2009 1:53 PM>>> >> I might have left it able to be called safe. Honestly I look more for >> human verifiable safety and correctness and it lacked those before and >> now does not. If that coincides with machine verifable safety, great. >> Either way you need C here for correctness and safety. It isn't >> 'nasty'. Not using C here would be nasty. I think you have it >> backwards. UNLESS the sizes and constants here are well known but >> reading docs quickly I didn't see that. Unsafe does not imply not >> portable. >> >> - Jay (phone) >> >> On Jul 21, 2009, at 9:03 AM, Tony Hosking >> wrote: >> >>> Hear, hear! >>> >>> >>> Sent from my iPhone >>> >>> On Jul 21, 2009, at 11:17 AM, "Randy Coleburn" >>> wrote: >>> >>>> Granted, I see that Term.m3 is an UNSAFE module, so that by >>>> definition means it is not portable. >>>> Why though do we want to replace it by nasty C code where non- >>>> portable stuff can be easily hidden? This is Modula-3. Why not >>>> fix the Modula-3 code so that it doesn't have to be UNSAFE? (My 2 >>>> cents.) >>>> --Randy >>>> >>>>>>> Jay Krell 7/21/2009 11:55 AM>>> >>>> CVSROOT:/usr/cvs >>>> Changes by:jkrell at birch.09/07/21 11:55:36 >>>> >>>> Added files: >>>> cm3/caltech-parser/term/src/: TermC.c >>>> >>>> Log message: >>>> initial copy of dangerous non portable Term.m3 to rewrite portably >>>> and have it do nothing silently on Win32 which should suffice, or >>>> if not, can probably be done better, specifically the MakeRaw >>>> function >>>> >>>> >>> >> > From wagner at elegosoft.com Wed Jul 22 11:26:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 11:26:42 +0200 Subject: [M3devel] cm3ide HTTP server, was: Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090721095537.18D8ECC806@birch.elegosoft.com> <4A65A389.1E75.00D7.1@scires.com> <225642A7-0FA4-4474-A37C-B59BD1F276CC@cs.purdue.edu> <4A66005F.1E75.00D7.1@scires.com> Message-ID: <20090722112642.vs5xve6934s8g4wk@mail.elegosoft.com> Quoting Jay K : > We should perhaps consider using the web server underpinnings of > cm3ide to run modula3.elegosoft.com. Really. If it is close to > already having the required functionality. No, it doesn't reach the area of complexity we usually expect in a web server nowadays. What we should do (which I intended to have done months ago :-/) is to setup a publicly accessible instance of the cm3ide GUI so people can play with it online. Some care must be taken though to not compromise our server... Anybody interested in doing this? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 22 16:06:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 16:06:45 +0200 Subject: [M3devel] tinderbox failures Message-ID: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Apart from four red boxes for new tinderbox clients, regression tests on niagara still fail: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248261714.32591 This used to work some days ago... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 16:28:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 14:28:30 +0000 Subject: [M3devel] tinderbox failures In-Reply-To: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Message-ID: Some of the new ones aren't terrible: LINUXLIBC6 failed the tests because it couldn't load dependent libraries. PPC_LINUX ran out of diskspace. SPARC32_LINUX looks ok. The problem on SOLgnu is it doesn't see the config file. Maybe my change yesterday will fix it? To always copy the config files? I'm very "timezone challenged". I never know when a Tinderbox run is in relation to my changes, and the changes column is no longer filled in since the server crash. :( How about we move cp_config_files earlier in upgrade.sh?? I can try that right now..I can't test it other than by watching the Tinderbox. If these are used with 5.4, hard to predict the result.. Go ahead with that? - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 16:06:45 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox failures > > Apart from four red boxes for new tinderbox clients, regression tests > on niagara still fail: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248261714.32591 > > This used to work some days ago... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 22 16:47:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 16:47:06 +0200 Subject: [M3devel] tinderbox failures In-Reply-To: References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> Message-ID: <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> Quoting Jay K : > Some of the new ones aren't terrible: > LINUXLIBC6 failed the tests because it couldn't load dependent libraries. > PPC_LINUX ran out of diskspace. > SPARC32_LINUX looks ok. > > > The problem on SOLgnu is it doesn't see the config file. > Maybe my change yesterday will fix it? To always copy the config files? > I'm very "timezone challenged". I never know when a Tinderbox > run is in relation to my changes, and the changes column is no longer > filled in since the server crash. :( That's one of the things that just work in Hudson. I thought the release built was after your changes, or I wouldn't have sent the mail yet. > How about we move cp_config_files earlier in upgrade.sh?? > I can try that right now..I can't test it other than > by watching the Tinderbox. If these are used with 5.4, hard to predict > the result.. Go ahead with that? I don't understand what you want to achieve with that. But I cannot check right now. 5.4 has just one single cm3.cfg file, and no sub dirs. I told you we'd need to cope with that. But then it seems to have worked for FreeBSD on Hudson: see http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/changes and http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/16/consoleFull which start with === 2009-07-21 23:17:10 build cm3 core in /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4 with last release /ad0e/home/hudson/work/cm3-inst/luthien/rel-5.4.0 Critical Mass Modula-3 version 5.4.0 last updated: 2006-10-11 configuration: /ad0e/home/hudson/work/cm3-inst/luthien/current--release-build/bin/cm3.cfg I don't know if that's conclusive though... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 17:06:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 15:06:10 +0000 Subject: [M3devel] tinderbox failures In-Reply-To: <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> References: <20090722160645.s41jc7xihw480k8c@mail.elegosoft.com> <20090722164706.qxgduzr9wk4w4w0g@mail.elegosoft.com> Message-ID: I need(ed) to read through/understand the scripts more. Yes, agreed, the configuration is best left alone when the preexisting cm3 is used -- which is always, now that I read it, it is copied either from lastok or last-rel. It should only be upgraded in association with cm3 being upgraded. Unless as a potshot to fix things, since the config files are fairly good and portable -- I think most of the stuff I removed was for pre-5.4 compat. Anyway, you can see in the log all the cp commands failed, because -v is not understood. Let's see how it goes now. My three new ones should go better, freed /lots/ of diskspace, made sure there were .a files in the lastok hand built installs, though odd that it should matter, the tests should use the new stuff. We'll see. I think I ran one of them lastrel by accident. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 16:47:06 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] tinderbox failures > > Quoting Jay K : > >> Some of the new ones aren't terrible: >> LINUXLIBC6 failed the tests because it couldn't load dependent libraries. >> PPC_LINUX ran out of diskspace. >> SPARC32_LINUX looks ok. >> >> >> The problem on SOLgnu is it doesn't see the config file. >> Maybe my change yesterday will fix it? To always copy the config files? >> I'm very "timezone challenged". I never know when a Tinderbox >> run is in relation to my changes, and the changes column is no longer >> filled in since the server crash. :( > > That's one of the things that just work in Hudson. > I thought the release built was after your changes, or I wouldn't have > sent the mail yet. > >> How about we move cp_config_files earlier in upgrade.sh?? >> I can try that right now..I can't test it other than >> by watching the Tinderbox. If these are used with 5.4, hard to predict >> the result.. Go ahead with that? > > I don't understand what you want to achieve with that. > But I cannot check right now. > > 5.4 has just one single cm3.cfg file, and no sub dirs. I told you > we'd need to cope with that. > > But then it seems to have worked for FreeBSD on Hudson: > > see > http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/changes > and > http://hudson.modula3.com:8080/view/cm3/job/cm3-release-build-FreeBSD4/16/consoleFull > > which start with > > === 2009-07-21 23:17:10 build cm3 core in > /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4 with last > release /ad0e/home/hudson/work/cm3-inst/luthien/rel-5.4.0 > Critical Mass Modula-3 version 5.4.0 > last updated: 2006-10-11 > configuration: > /ad0e/home/hudson/work/cm3-inst/luthien/current--release-build/bin/cm3.cfg > > I don't know if that's conclusive though... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From eiserlohpp at yahoo.com Wed Jul 22 17:53:09 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 22 Jul 2009 08:53:09 -0700 (PDT) Subject: [M3devel] m3middle compile failure (overrides) Message-ID: <982128.58200.qm@web56808.mail.re3.yahoo.com> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, but failed. The m3overrides file for m3middle, was recently changed, and now causes compilation failure. WAS: if not defined("BOOT") override("m3core", ROOT & "/m3-libs") override("libm3", ROOT & "/m3-libs") end NOW: include(ROOT & "/m3overrides") It is looking in the root of the entire source tree, for a non-existent m3overrides file, and quake rightly complains. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Wed Jul 22 17:55:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 15:55:46 +0000 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <982128.58200.qm@web56808.mail.re3.yahoo.com> References: <982128.58200.qm@web56808.mail.re3.yahoo.com> Message-ID: The file exists. cvs -z3 upd - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 08:53:09 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3middle compile failure (overrides) > > > I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, > but failed. > > > The m3overrides file for m3middle, was recently changed, > and now causes compilation failure. > > WAS: > if not defined("BOOT") > override("m3core", ROOT & "/m3-libs") > override("libm3", ROOT & "/m3-libs") > end > > > NOW: > include(ROOT & "/m3overrides") > > > It is looking in the root of the entire source tree, > for a non-existent m3overrides file, and quake rightly > complains. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Wed Jul 22 18:02:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 16:02:03 +0000 Subject: [M3devel] NT386 problem with C runtime/tools versions Message-ID: I just discovered that..well..if the user has a different version of Visual C++ tools/libraries than the distribution is built with..many scenarios don't work -- e.g. not using build_standalone. It should have worked better. Until/unless I work out something better here, I'd suggest we build multiple releases, one for each likely to be used toolset. 8.0/2005 and 9.0/2008 are probably a good mix currently. I guess in some ways this isn't surprising, IF any of the Modula-3 libraries traffic in either FILE* (fopen/fread/fwrite/fclose) or "int file" (open/close/read/write), but they might not. Or malloc/free, which they might. We might consider ensuring the untraced heap is via HeapAlloc(GetProcessHeap()) in order to be independent of the C runtime -- in general the C runtime dependencies probably can/should be limited, but this is another topic, another release. - Jay From jay.krell at cornell.edu Wed Jul 22 18:04:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 16:04:15 +0000 Subject: [M3devel] Tinderbox should always run tests? Message-ID: Olaf, is there any reason every Tinderbox run shouldn't run the tests? - Jay From rcoleburn at scires.com Wed Jul 22 18:06:16 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 22 Jul 2009 12:06:16 -0400 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> Message-ID: <4A670075.1E75.00D7.1@scires.com> Jay: I tried the python script, but it did not work for me. I installed python 2.6.2. Should I have used 3.1? There was a note about 3.1 not being compatible with some stuff. I discovered a problem in the PkgInfo.txt where the 3 juno packages didn't have the path "juno-2/" prepended, so I've fixed that and I've updated my local CVS copy to be current with the repository, and rebuilt everything using my script, e.g. "do-cm3 all clean buildship". The only packages from PkgInfo.txt that fail to build (i.e., cm3 exits with errorlevel >0) on Windows now are: m3-sys/m3cc caltech-parser/parserlib/parserlib/test Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on that package fails. Regards, Randy Coleburn >>> Jay K 7/21/2009 6:39 PM >>> I use the Python all the time on various platforms. It works. The .cmds I wrote I rarely use, and then, only on Windows. I thought your list of failures would be down to just m3cc. What are they? - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Wed Jul 22 18:34:10 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 22 Jul 2009 09:34:10 -0700 (PDT) Subject: [M3devel] m3middle compile failure (overrides) Message-ID: <817070.81781.qm@web56807.mail.re3.yahoo.com> Hi Jay, Peter said: >I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, but failed. Jay said: >The file exists. >cvs -z3 upd > >- Jay No it does not exist in the tarball. When I did a cvs update in my CVS tree, yes it is there, but not in the tarball. I downloaded a tarball, and attempted to build in that. The scripts used to build the tarballs look like they explicitly builds a list of files/directories to include and exclude. The toplevel m3overrides file is not listed in the build script, so does not get into ".tar-include". You added a file to the top level of the source tree, and the build script (make-src-dist-all.sh, and family) were not updated. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed Jul 22 18:56:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 18:56:48 +0200 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <817070.81781.qm@web56807.mail.re3.yahoo.com> References: <817070.81781.qm@web56807.mail.re3.yahoo.com> Message-ID: <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> Well, there are always side-effects to this kind of global changes. Jay, please fix the scripts. Thanks, Olaf Quoting Peter Eiserloh : > Hi Jay, > > > Peter said: >> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, > but failed. > > > Jay said: >> The file exists. >> cvs -z3 upd >> >> - Jay > > No it does not exist in the tarball. When I did a cvs update > in my CVS tree, yes it is there, but not in the tarball. > I downloaded a tarball, and attempted to build in that. > > The scripts used to build the tarballs look like they > explicitly builds a list of files/directories to include > and exclude. The toplevel m3overrides file is not listed > in the build script, so does not get into ".tar-include". > > You added a file to the top level of the source tree, and > the build script (make-src-dist-all.sh, and family) were > not updated. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 22 19:00:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Jul 2009 19:00:12 +0200 Subject: [M3devel] Tinderbox should always run tests? In-Reply-To: References: Message-ID: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> Quoting Jay K : > Olaf, is there any reason every Tinderbox run shouldn't run the tests? We don't want to run them both after the release- and the lastok- build (to save resources). It should be no problem to adapt the scripts for any specific setup (like I did on birch). If you don't run the release build, you should of course add running the tests after the lastok build. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 22 21:47:37 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 22 Jul 2009 12:47:37 -0700 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A670075.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> Message-ID: <050B1665-CAF7-4520-9613-B5EB0AD028E2@hotmail.com> I tried python 3.x once it didn't work. I stay with 2.x for now. - clean often does not work, I use realclean. I will check the test directory. You should be able to filter out m3cc. I might. - Jay (phone) On Jul 22, 2009, at 9:06 AM, "Randy Coleburn" wrote: > Jay: > > I tried the python script, but it did not work for me. I installed > python 2.6.2. Should I have used 3.1? There was a note about 3.1 > not being compatible with some stuff. > > I discovered a problem in the PkgInfo.txt where the 3 juno packages > didn't have the path "juno-2/" prepended, so I've fixed that and > I've updated my local CVS copy to be current with the repository, > and rebuilt everything using my script, e.g. "do-cm3 all clean > buildship". > > The only packages from PkgInfo.txt that fail to build (i.e., cm3 > exits with errorlevel >0) on Windows now are: > m3-sys/m3cc > caltech-parser/parserlib/parserlib/test > > Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on > that package fails. > > Regards, > Randy Coleburn > > >>> Jay K 7/21/2009 6:39 PM >>> > > I use the Python all the time on various platforms. It works. > The .cmds I wrote I rarely use, and then, only on Windows. > I thought your list of failures would be down to just m3cc. What are > they? > > - Jay From jay.krell at cornell.edu Wed Jul 22 22:35:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 20:35:36 +0000 Subject: [M3devel] Tinderbox should always run tests? In-Reply-To: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> References: <20090722190012.onh9vgwlb4ksoks8@mail.elegosoft.com> Message-ID: Next question -- how to get the tests status to appear? I see the sample at the end of defs.sh -- call main | logfilter | mail. But how do integrate that with ./tinderbox-build cm3.build? Call them both one after the other? I don't see relevant tinderbox or cm3 in /etc/cron* /etc/cron*/* on birch. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 19:00:12 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: Tinderbox should always run tests? > > Quoting Jay K : > >> Olaf, is there any reason every Tinderbox run shouldn't run the tests? > > We don't want to run them both after the release- and the lastok- > build (to save resources). It should be no problem to adapt the > scripts for any specific setup (like I did on birch). > > If you don't run the release build, you should of course add running > the tests after the lastok build. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 22 22:37:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 22 Jul 2009 20:37:15 +0000 Subject: [M3devel] m3middle compile failure (overrides) In-Reply-To: <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> References: <817070.81781.qm@web56807.mail.re3.yahoo.com> <20090722185648.djbjbykacgcgckos@mail.elegosoft.com> Message-ID: oops, sorry, should be ok for the next set. - Jay ---------------------------------------- > Date: Wed, 22 Jul 2009 18:56:48 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3middle compile failure (overrides) > > Well, there are always side-effects to this kind of global changes. > Jay, please fix the scripts. > > Thanks, > > Olaf > > Quoting Peter Eiserloh : > >> Hi Jay, >> >> >> Peter said: >>> I just attempted to compile cm3-src-all-d5.8.2-2009-07-22-00-11-09.tgz, >> but failed. >> >> >> Jay said: >>> The file exists. >>> cvs -z3 upd >>> >>> - Jay >> >> No it does not exist in the tarball. When I did a cvs update >> in my CVS tree, yes it is there, but not in the tarball. >> I downloaded a tarball, and attempted to build in that. >> >> The scripts used to build the tarballs look like they >> explicitly builds a list of files/directories to include >> and exclude. The toplevel m3overrides file is not listed >> in the build script, so does not get into ".tar-include". >> >> You added a file to the top level of the source tree, and >> the build script (make-src-dist-all.sh, and family) were >> not updated. >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 23 07:55:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 07:55:03 +0200 Subject: [M3devel] NT386 problem with C runtime/tools versions In-Reply-To: References: Message-ID: <20090723075503.bzhj08ps004c00oc@mail.elegosoft.com> Quoting Jay K : > > I just discovered that..well..if the user has a different version of > Visual C++ tools/libraries than the distribution is built > with..many scenarios don't work -- e.g. not using build_standalone. > It should have worked better. > Until/unless I work out something better here, I'd suggest we build > multiple releases, one for each likely to be used toolset. 8.0/2005 > and 9.0/2008 are probably a good mix currently. > > > I guess in some ways this isn't surprising, IF any of the Modula-3 > libraries traffic in either FILE* (fopen/fread/fwrite/fclose) or > "int file" (open/close/read/write), but they might not. Or > malloc/free, which they might. We might consider ensuring the > untraced heap is via HeapAlloc(GetProcessHeap()) in order to be > independent of the C runtime -- in general the C runtime > dependencies probably can/should be limited, but this is another > topic, another release. Please add these topics in trac to the roadmap for the next release. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 11:34:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 11:34:50 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: <4A670075.1E75.00D7.1@scires.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> Message-ID: <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Quoting Randy Coleburn : > The only packages from PkgInfo.txt that fail to build (i.e., cm3 > exits with errorlevel >0) on Windows now are: > m3-sys/m3cc > caltech-parser/parserlib/parserlib/test > > Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on > that package fails. Wrong (missing) depencencies or heavy quake hacking? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 15:42:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 15:42:53 +0200 Subject: [M3devel] CM3 Release Engineering Status Message-ID: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> I updated the roadmap in our trac https://projects.elego.de/cm3/roadmap and created several tickets, see https://projects.elego.de/cm3/timeline This morning I moved the RC2 tag to a position which should now be almost stable (hopefully), but I don't really know yet. Many tests are pending. Any help on resolving the tickets and other issues not yet recorded in trac will be appreciated. I'm not sure if we can cope with all the tasks during the weekend; I'll move the milestone date if necessary. Please write a ticket for every issue that is related to one of the release milestones (one on the formsedit crash is still missing, for example). Again, if you need access to trac, let me know; the web admin GUI is broken and I need to add accounts and passwords from the command line. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jul 23 17:10:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 23 Jul 2009 11:10:42 -0400 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> Message-ID: <4A6844E7.1E75.00D7.1@scires.com> Olaf: My browser is reporting a problem with the security certificate used for these web pages. I can work on "install.cmd" for you. I haven't had any crash with cm3ide. If someone can give details, I'll try to check into it. With regard to #1007, I already sent in the script you requested. Here it is again. Your script can be expressed in Windows .CMD format as follows: REM ---BEGIN--- @echo off for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p goto End :ShipIt echo ...shipping %1... pushd %1 cm3 -ship %SHIPARGS% popd echo. goto :EOF :End echo done @echo on REM ---END--- Of course, the REM lines at the beginning/end are optional, I just put them there to show start/end of the script. Also, you would want to replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of folders to be processed. You can separate them by blank spaces or semi-colons, but if you have a path with an embedded space, you will need to put double quotes around the path. FYI: If your list of paths is in a text file, there is another form of the FOR command that would work to process the list from that file. I don't mind writing .CMD files, so if you and Jay want some help in this area, I am willing to volunteer. Regards, Randy Coleburn >>> Olaf Wagner 7/23/2009 9:42 AM >>> I updated the roadmap in our trac https://projects.elego.de/cm3/roadmap and created several tickets, see https://projects.elego.de/cm3/timeline This morning I moved the RC2 tag to a position which should now be almost stable (hopefully), but I don't really know yet. Many tests are pending. Any help on resolving the tickets and other issues not yet recorded in trac will be appreciated. I'm not sure if we can cope with all the tasks during the weekend; I'll move the milestone date if necessary. Please write a ticket for every issue that is related to one of the release milestones (one on the formsedit crash is still missing, for example). Again, if you need access to trac, let me know; the web admin GUI is broken and I need to add accounts and passwords from the command line. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 23 17:21:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 23 Jul 2009 15:21:13 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <4A6844E7.1E75.00D7.1@scires.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: > My browser is reporting a problem with the security certificate used for these web pages. I reported that, for IE8. Workaround: Firefox or Opera. - Jay From wagner at elegosoft.com Thu Jul 23 18:13:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 18:13:14 +0200 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <4A6844E7.1E75.00D7.1@scires.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: <20090723181314.3csixgnyr4o84gsc@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > My browser is reporting a problem with the security certificate used > for these web pages. That may well be. I think you should be able to ignore those warnings. Admin resources are scarce currently, not to say non-existent :-/ I've got no problems with trac access with either Firefox or Opera. > I can work on "install.cmd" for you. > > I haven't had any crash with cm3ide. If someone can give details, I'll > try to check into it. > > With regard to #1007, I already sent in the script you requested. Here > it is again. I noticed you had send that, but haven't come round to include the generation in make-dist.sh. I'm rather collecting and recording all the tasks that need to be done (in spare minutes at my paid work). Thanks again, Olaf > Your script can be expressed in Windows .CMD format as follows: > > REM ---BEGIN--- > @echo off > for %%p in (m3-win\import-libs; ... m3-comm\tcp;) do call :ShipIt %%p > goto End > > :ShipIt > echo ...shipping %1... > pushd %1 > cm3 -ship %SHIPARGS% > popd > echo. > goto :EOF > > :End > echo done > @echo on > REM ---END--- > > Of course, the REM lines at the beginning/end are optional, I just put > them there to show start/end of the script. Also, you would want to > replace "m3-win\import-libs; ... m3-comm\tcp;" with the actual list of > folders to be processed. You can separate them by blank spaces or > semi-colons, but if you have a path with an embedded space, you will > need to put double quotes around the path. > > FYI: If your list of paths is in a text file, there is another form of > the FOR command that would work to process the list from that file. > > I don't mind writing .CMD files, so if you and Jay want some help in > this area, I am willing to volunteer. > > Regards, > Randy Coleburn > >>>> Olaf Wagner 7/23/2009 9:42 AM >>> > I updated the roadmap in our trac > > https://projects.elego.de/cm3/roadmap > > and created several tickets, see > > https://projects.elego.de/cm3/timeline > > This morning I moved the RC2 tag to a position which should > now be almost stable (hopefully), but I don't really know yet. > Many tests are pending. > > Any help on resolving the tickets and other issues not yet > recorded in trac will be appreciated. I'm not sure if we can cope > with all the tasks during the weekend; I'll move the milestone > date if necessary. > > Please write a ticket for every issue that is related to one of > the release milestones (one on the formsedit crash is still missing, > for example). > > Again, if you need access to trac, let me know; the web admin GUI > is broken and I need to add accounts and passwords from the command > line. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 23 18:16:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 23 Jul 2009 18:16:08 +0200 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> Message-ID: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Quoting Jay K : > >> My browser is reporting a problem with the security certificate >> used for these web pages. > > I reported that, for IE8. > Workaround: Firefox or Opera. And you found no way to turn it off in Internet Explorer? Surely Microsoft cannot assume that the whole Internet is officially certified? We'd need to raise some funds if we wanted to do that for cm3... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 06:08:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 04:08:31 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Thu, 23 Jul 2009 18:16:08 +0200 > From: wagner > To: jay > CC: m3devel; m3-support; admins > Subject: RE: [M3devel] CM3 Release Engineering Status > > Quoting Jay K : > >> >>> My browser is reporting a problem with the security certificate >>> used for these web pages. >> >> I reported that, for IE8. >> Workaround: Firefox or Opera. > > And you found no way to turn it off in Internet Explorer? > > Surely Microsoft cannot assume that the whole Internet is > officially certified? We'd need to raise some funds if we wanted > to do that for cm3... > > Olaf I hadn't but now I have. The first error you get: There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority. The security certificate presented by this website was issued for a different website's address. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). More information You only get once per running IE and browsing to the site. Not a big deal. You can maybe add the certificate to some setting to ignore in future. I think this is the part you (Olaf and Randy) are referring to. The bigger problem is that once you ignore this, every single click in Trac brings up another message, about displaying a mix of secure/insecure content. I just found the fix to that: http://blogs.msdn.com/askie/archive/2009/05/14/mixed-content-and-internet-explorer-8-0.aspx A setting to for mixed content: enable, disable, prompt. Change from prompt to enable. I'm not sure if you can scope it to just modula3/elegosoft (maybe you can make a custom zone, add the sites, change the settings?) It sounds like it is only for IE8. That for IE7 there is no fix? Maybe for IE6 there was no prompt? I'm using IE8. Maybe you are supposed to replicate all the insecure stuff on the secure site? I don't know. - Jay From jay.krell at cornell.edu Fri Jul 24 06:45:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 04:45:42 +0000 Subject: [M3devel] CM3 Release Engineering Status In-Reply-To: <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: > Surely Microsoft cannot assume that the whole Internet is > officially certified? We'd need to raise some funds if we wanted > to do that for cm3... > > Olaf How much? It looks like..verisign..cheapest option.. $600/year $1100/2 years (save $100) $1600/3 years (save $200) good enough? Can six people each put up $100, check payable to Olaf, he volunteers his time (or make it seven people, or $110 each), and we'll worry about it again in a year? I can. Or ignore it? Double the price for 128bit instead of 40bit. I don't understand the "extended validation, gren address bar". Shop around maybe it is availabe cheaper? Or just ignore it? Maybe they offer a discount for open source projects? I'll poke around a bit more.. GoDaddy seems to offer much better. Free for a year for open source projects, 256 bit, a $30 value. A $30 value, hm. So..if you don't want the bureacracy of being an official open source project.. They really do offer stuff starting at $30/year. Their most expensive option seems to be $240/year. Multi-year discounts range from 10% to 25%. So..just $30/year? Or free due to being open source? This sounds more viable and maybe worthwhile. Or just ignore it? - Jay From wagner at elegosoft.com Fri Jul 24 09:55:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 09:55:34 +0200 Subject: [M3devel] Trusted certificates for Elego's web services In-Reply-To: References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> Message-ID: <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> I'll put this topic on the agenda of our next infrastructure meeting at Elego. It will be some time, since our 'prime administrator' is on a long vacation in the US. I've never really understood why I should feel more secure if a large enterprise whose procedures I don't know and can neither examine nor validate certifies that I bought just that certificate from them. Nor do I see it really necessary for those who don't engage in online shopping or trading. I do see that it's an interesting business though (financial perspective). However, it seems to become more and more expected that one has certificates from a trusted issuer, so it will affect all Elego customers, too. We'll have to get certificates for all our web servers, which will then include the CM3 one. I'll let you know if we can take over the costs :-) Let's ignore this issue for while... Olaf Quoting Jay K : >> Surely Microsoft cannot assume that the whole Internet is >> officially certified? We'd need to raise some funds if we wanted >> to do that for cm3... >> >> Olaf > > How much? > > > It looks like..verisign..cheapest option.. > $600/year > $1100/2 years (save $100) > $1600/3 years (save $200) > > good enough? > > Can six people each put up $100, check payable to Olaf, > he volunteers his time (or make it seven people, or $110 each), and we'll > worry about it again in a year? > I can. > > Or ignore it? > > Double the price for 128bit instead of 40bit. > > I don't understand the "extended validation, gren address bar". > > Shop around maybe it is availabe cheaper? > > Or just ignore it? > > Maybe they offer a discount for open source projects? > > I'll poke around a bit more.. > > > GoDaddy seems to offer much better. > Free for a year for open source projects, 256 bit, a $30 value. > A $30 value, hm. > > > So..if you don't want the bureacracy of being an official open > source project.. > They really do offer stuff starting at $30/year. > Their most expensive option seems to be $240/year. > Multi-year discounts range from 10% to 25%. > > > So..just $30/year? > Or free due to being open source? > > This sounds more viable and maybe worthwhile. Or just ignore it? > > > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 10:53:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:53:24 +0000 Subject: [M3devel] Hudson errors in cvs upd. Message-ID: A SCM change trigger started this job Building on master [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" U m3-libs/libm3/src/random/m3makefile U m3-libs/m3core/src/Csupport/m3makefile U m3-libs/m3core/src/time/POSIX/m3makefile ? m3-libs/unittest/AMD64_LINUX U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN ... cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' U m3-sys/m3middle/src/Target.i3 U m3-sys/m3middle/src/Target.m3 U m3-sys/m3middle/src/m3makefile U scripts/pkgmap.sh ? scripts/PKGS SCM check out aborted Finished: FAILURE I know I was thinking of deleting those directories but I don't think I did. - Jay From jay.krell at cornell.edu Fri Jul 24 10:57:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:57:09 +0000 Subject: [M3devel] Hudson errors out of diskspace Message-ID: Here's another: new source -> compiling ../FreeBSD4/cm3unix.c ../FreeBSD4/cm3unix.c:3: fatal error: error writing to /var/tmp/ccVwJXWF.s: No space left on device Hudson is looking like a big improvement though -- the last success, last failure columns, the list of changes in a build, the quick access to the full output. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: Hudson errors in cvs upd. > Date: Fri, 24 Jul 2009 08:53:24 +0000 > > > A SCM change trigger started this job > Building on master > [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" > U m3-libs/libm3/src/random/m3makefile > U m3-libs/m3core/src/Csupport/m3makefile > U m3-libs/m3core/src/time/POSIX/m3makefile > ? m3-libs/unittest/AMD64_LINUX > U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN > ... > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' > U m3-sys/m3middle/src/Target.i3 > U m3-sys/m3middle/src/Target.m3 > U m3-sys/m3middle/src/m3makefile > U scripts/pkgmap.sh > ? scripts/PKGS > SCM check out aborted > Finished: FAILURE > > > I know I was thinking of deleting those directories but I don't think I did. > > > - Jay From jay.krell at cornell.edu Fri Jul 24 10:57:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 08:57:50 +0000 Subject: [M3devel] Hudson errors out of diskspace Message-ID: also: /var/tmp/hudson46743.sh: line 11: /ad0e/home/hudson/workspace/cm3-release-build-FreeBSD4/scripts/do-cm3-all.sh: No such file or directory could be related to out of diskspace though. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: RE: Hudson errors out of diskspace > Date: Fri, 24 Jul 2009 08:57:09 +0000 > > > Here's another: > > > new source -> compiling ../FreeBSD4/cm3unix.c > ../FreeBSD4/cm3unix.c:3: fatal error: error writing to /var/tmp/ccVwJXWF.s: No space left on device > > > Hudson is looking like a big improvement though -- the last success, last failure columns, the list of changes in a build, the quick access to the full output. > > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; wagner at elegosoft.com >> Subject: Hudson errors in cvs upd. >> Date: Fri, 24 Jul 2009 08:53:24 +0000 >> >> >> A SCM change trigger started this job >> Building on master >> [cm3] $ cvs -q -z0 update -PdC -D "Friday, July 24, 2009 6:58:58 AM UTC" >> U m3-libs/libm3/src/random/m3makefile >> U m3-libs/m3core/src/Csupport/m3makefile >> U m3-libs/m3core/src/time/POSIX/m3makefile >> ? m3-libs/unittest/AMD64_LINUX >> U m3-sys/cminstall/src/config-no-install/AMD64_DARWIN >> ... >> cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' >> cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' >> U m3-sys/m3middle/src/Target.i3 >> U m3-sys/m3middle/src/Target.m3 >> U m3-sys/m3middle/src/m3makefile >> U scripts/pkgmap.sh >> ? scripts/PKGS >> SCM check out aborted >> Finished: FAILURE >> >> >> I know I was thinking of deleting those directories but I don't think I did. >> >> >> - Jay From stsp at elego.de Fri Jul 24 11:09:16 2009 From: stsp at elego.de (Stefan Sperling) Date: Fri, 24 Jul 2009 10:09:16 +0100 Subject: [M3devel] Trusted certificates for Elego's web services In-Reply-To: <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> References: <20090723154253.bgcihtl6o0c08c40@mail.elegosoft.com> <4A6844E7.1E75.00D7.1@scires.com> <20090723181608.ut5jq6t18kc4wk8o@mail.elegosoft.com> <20090724095534.s557nrl748wgcwk8@mail.elegosoft.com> Message-ID: <20090724090916.GC3671@jack.stsp.name> On Fri, Jul 24, 2009 at 09:55:34AM +0200, Olaf Wagner wrote: > We'll have to get certificates for all our web servers, which will > then include the CM3 one. I'll let you know if we can take over the > costs :-) > > Let's ignore this issue for while... There are local certificate issuers in Germany, too. E.g. Deutsche Telekom does it and their root CA even made it into Firefox now: https://bugzilla.mozilla.org/show_bug.cgi?id=378882 They might still be operating as opaquely as Verisign but maybe they are less expensive. And they'd probably be less complicated for elego to deal with than any issuer in the US. They've also signed certs for DFN members (German universities and research institutions). E.g. if you go here you can see a chain going up to Telekom: https://webmail.spline.inf.fu-berlin.de/ >>> Surely Microsoft cannot assume that the whole Internet is >>> officially certified? I have a feeling they'd like to, but more in terms of who controls the procotols being used on the net, not necessarily with respect to SSL certs. That said, newer Firefox versions have also been pushing the user experience with self-signed certs far down in an attempt to get website admins to get their certs signed. Stefan From wagner at elegosoft.com Fri Jul 24 11:44:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 11:44:38 +0200 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: References: Message-ID: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Quoting Jay K : > Here's another: > > new source -> compiling ../FreeBSD4/cm3unix.c > ../FreeBSD4/cm3unix.c:3: fatal error: error writing to > /var/tmp/ccVwJXWF.s: No space left on device That was on my home machine because core dumps from m3tests were accumulating in /var/tmp. I've now set the core dump limit to 0 for those jobs. > Hudson is looking like a big improvement though -- the last success, > last failure columns, the list of changes in a build, the quick > access to the full output. Yes. I've been using it for about half a year now, and apart from the fact that it's resource hungry and sometimes slow, it's easy to use and configure. And you find a plug-in for almost everything. Since yesterday afternoon all necessary plug-ins for interaction with other servers should be installed. I've just moved the crontab jobs from user m3 on birch to hudson, see http://hudson.modula3.com:8080/view/m3-www-support/. My network connection is very unstable currently, so more failures are to be expected. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 12:44:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 10:44:06 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure Message-ID: I'm seeing wierd stuff. On PPC_LINUX. Compiling some files hangs. Such as M3Front.m3. It is actually looping forever in Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") which, you know, other than feeding it bad data, or corrupting its stack when it calls out to our lock/unlock, we can't mess up. I can watch what strings it gets on other systems and/or make a standalone case that hangs. While investigating this I hit control-c on a cm3 and hit: new source -> compiling SchedulerPosix.i3 (hung here) *** *** runtime error: *** failed. *** file "..\src\runtime\common\RTCollector.m3", line 1087 *** Aborted PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = BEGIN WHILE h < he DO line 1087 Maybe we don't deal with control-c at arbitrary points?? I was able to reproduce this assertion failure twice in a row.. though it moved to line 1089 the second time. PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = BEGIN WHILE h < he DO IF h.gray THEN line 1089 I verified that the hang compiling SchedulerPosix.i3 is also related to floating point conversion. This time in m3_dtoa. I will look further. Maybe my config file changes..but seems odd.. - Jay - Jay From jay.krell at cornell.edu Fri Jul 24 12:48:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 10:48:09 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: References: Message-ID: sorry, nevermind. It reproed on SOLgnu and then I found the problem. It's good to test little and big endian systems. I had broken all big endian systems. Should be ok now. I'll proceed to try to repro the formsedit crash. :) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 24 Jul 2009 10:44:06 +0000 > Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure > > > I'm seeing wierd stuff. > > On PPC_LINUX. From jay.krell at cornell.edu Fri Jul 24 13:41:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 11:41:25 +0000 Subject: [M3devel] status report on Windows XP In-Reply-To: <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Message-ID: This should be fixed now. I assume it was broken on all platforms. -clean doesn't work well. Maybe time to make -clean just do the same as -realclean? - Jay ---------------------------------------- > Date: Thu, 23 Jul 2009 11:34:50 +0200 > From: wagner@ > To: m3devel@ > Subject: Re: [M3devel] status report on Windows XP > > Quoting Randy Coleburn : > >> The only packages from PkgInfo.txt that fail to build (i.e., cm3 >> exits with errorlevel>0) on Windows now are: >> m3-sys/m3cc >> caltech-parser/parserlib/parserlib/test >> >> Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on >> that package fails. > > Wrong (missing) depencencies or heavy quake hacking? > > Olaf > -- From wagner at elegosoft.com Fri Jul 24 13:56:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 13:56:15 +0200 Subject: [M3devel] status report on Windows XP In-Reply-To: References: <4A653548.1E75.00D7.1@scires.com> <4A653815.1E75.00D7.1@scires.com> <4A65A009.1E75.00D7.1@scires.com> <4A6601D6.1E75.00D7.1@scires.com> <4A670075.1E75.00D7.1@scires.com> <20090723113450.7lhx97rfs480g8kc@mail.elegosoft.com> Message-ID: <20090724135615.n9htefpvkw4gogw8@mail.elegosoft.com> Quoting Jay K : > > This should be fixed now. > I assume it was broken on all platforms. > -clean doesn't work well. > Maybe time to make -clean just do the same as -realclean? I wouldn't mind that. Perhaps others do? Olaf > ---------------------------------------- >> Date: Thu, 23 Jul 2009 11:34:50 +0200 >> From: wagner@ >> To: m3devel@ >> Subject: Re: [M3devel] status report on Windows XP >> >> Quoting Randy Coleburn : >> >>> The only packages from PkgInfo.txt that fail to build (i.e., cm3 >>> exits with errorlevel>0) on Windows now are: >>> m3-sys/m3cc >>> caltech-parser/parserlib/parserlib/test >>> >>> Interestingly, although "m3-obliq/obliqrt" builds, "cm3 -clean" on >>> that package fails. >> >> Wrong (missing) depencencies or heavy quake hacking? >> >> Olaf >> -- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 24 14:04:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 12:04:42 +0000 Subject: [M3devel] bourne shell error on Solaris tinderbox Message-ID: Tinderbox on Solaris: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? unexpected Perl or Python would be more portable perhaps. Or Modula-3? (Seriously: Python). - Jay From wagner at elegosoft.com Fri Jul 24 15:17:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 15:17:07 +0200 Subject: [M3devel] bourne shell error on Solaris tinderbox In-Reply-To: References: Message-ID: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> Quoting Jay K : > Tinderbox on Solaris: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 > > /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? > unexpected Sorry for that. Solaris has ksh, which understands POSIX command substitution, but other systems won't have that. Can we assume bash, or should I just replace all $() by backquotes again? > Perl or Python would be more portable perhaps. Or Modula-3? > (Seriously: Python). I don't want to have that big dependency for all tests... Otherwise I'd agree: always use Python if possible. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jul 24 16:06:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 24 Jul 2009 10:06:52 -0400 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: References: Message-ID: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> Yeah, I don't think control C works reasonably for all points in GC. Perhaps just eliminate the signal handler? Not sure. On 24 Jul 2009, at 06:44, Jay K wrote: > > I'm seeing wierd stuff. > > On PPC_LINUX. > > Compiling some files hangs. > Such as M3Front.m3. > > It is actually looping forever in > > Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") > > > which, you know, other than feeding it bad data, or corrupting > its stack when it calls out to our lock/unlock, we can't mess up. > > > I can watch what strings it gets on other systems and/or make > a standalone case that hangs. > > > While investigating this I hit control-c on a cm3 and hit: > > > new source -> compiling SchedulerPosix.i3 (hung here) > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > Aborted > > > > PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = > BEGIN > WHILE h < he DO > > line 1087 > > > Maybe we don't deal with control-c at arbitrary points?? > > > I was able to reproduce this assertion failure twice in a row.. > though it moved to line 1089 the second time. > > > > PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = > BEGIN > WHILE h < he DO > > > IF h.gray THEN > line 1089 > > > I verified that the hang compiling SchedulerPosix.i3 is also related > to floating point conversion. > This time in m3_dtoa. > > > I will look further. > Maybe my config file changes..but seems odd.. > > - Jay > > > - Jay > > From jay.krell at cornell.edu Fri Jul 24 16:08:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 14:08:08 +0000 Subject: [M3devel] bourne shell error on Solaris tinderbox In-Reply-To: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> References: <20090724151707.cdm9p13c4kk4gwog@mail.elegosoft.com> Message-ID: Whatever works automatically or with little documented/errored fuss. (use #!/bin/bash and there'll be a clear error.) I doubt bash is on most systems by default. I figure if you have to use something that isn't installed by default, might as well be Python. (Esp. once I get it working on MIPS64_OPENBSD! Probably just have to turn off libffi.) - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 15:17:07 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: bourne shell error on Solaris tinderbox > > Quoting Jay K : > >> Tinderbox on Solaris: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433519.10119 >> >> /scratch/hosking/work/cm3-ws/niagara-2009-07-24-10-47-30/cm3/scripts/pkgmap.sh: syntax error at line 256: `(? >> unexpected > > Sorry for that. Solaris has ksh, which understands POSIX command > substitution, but other systems won't have that. > Can we assume bash, or should I just replace all $() by backquotes > again? > >> Perl or Python would be more portable perhaps. Or Modula-3? >> (Seriously: Python). > > I don't want to have that big dependency for all tests... > Otherwise I'd agree: always use Python if possible. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 24 16:11:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 14:11:41 +0000 Subject: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure In-Reply-To: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> References: <87327A86-4FC6-4BCA-8355-F961568AA71E@cs.purdue.edu> Message-ID: Right..so I had a big blatant bug..but the next thing to try is feeding this string to the convert functions through a "safe" path and see if it hangs.. and address the control-c issue maybe (if it is process kill though, fix is to just run less code..) >> Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") (note that hotmail ruined the pragmas due to the angle brackets..) and I'll have to find what the parameter to m3_dtoawas. Btw, the bug was, quake: if defined("FOO") if equal("FOO", "BAR") something else something else instead of if defined("FOO") if equal(FOO, "BAR") - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] PPC_LINUX hangs in m3_strtod? and an assertion failure > Date: Fri, 24 Jul 2009 10:06:52 -0400 > > Yeah, I don't think control C works reasonably for all points in GC. > Perhaps just eliminate the signal handler? Not sure. > > > > On 24 Jul 2009, at 06:44, Jay K wrote: > >> >> I'm seeing wierd stuff. >> >> On PPC_LINUX. >> >> Compiling some files hangs. >> Such as M3Front.m3. >> >> It is actually looping forever in >> >> Breakpoint 1, m3_strtod (s00=0x7feb9ef0 "4.9406564584124654e-324") >> >> >> which, you know, other than feeding it bad data, or corrupting >> its stack when it calls out to our lock/unlock, we can't mess up. >> >> >> I can watch what strings it gets on other systems and/or make >> a standalone case that hangs. >> >> >> While investigating this I hit control-c on a cm3 and hit: >> >> >> new source -> compiling SchedulerPosix.i3 (hung here) >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >> *** >> Aborted >> >> >> >> PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = >> BEGIN >> WHILE h < he DO >> >> line 1087 >> >> >> Maybe we don't deal with control-c at arbitrary points?? >> >> >> I was able to reproduce this assertion failure twice in a row.. >> though it moved to line 1089 the second time. >> >> >> >> PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) = >> BEGIN >> WHILE h < he DO >> >> >> IF h.gray THEN >> line 1089 >> >> >> I verified that the hang compiling SchedulerPosix.i3 is also related >> to floating point conversion. >> This time in m3_dtoa. >> >> >> I will look further. >> Maybe my config file changes..but seems odd.. >> >> - Jay >> >> >> - Jay >> >> > From hosking at cs.purdue.edu Fri Jul 24 16:14:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 24 Jul 2009 10:14:08 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090724071308.62663CC81C@birch.elegosoft.com> References: <20090724071308.62663CC81C@birch.elegosoft.com> Message-ID: <6309A64A-4FD5-4EF6-B58E-7E791F1E6DF7@cs.purdue.edu> On 24 Jul 2009, at 09:13, Jay Krell wrote: > Log message: > VAX was actually Ultrix apparently, not VMS, so remove VMS entry > until we have an actual VMS port Very amusing! :-) From rcoleburn at scires.com Fri Jul 24 17:47:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 24 Jul 2009 11:47:10 -0400 Subject: [M3devel] Hudson question In-Reply-To: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: <4A699EF1.1E75.00D7.1@scires.com> Olaf: If we switch to Hudson, does that offer any improvement in the Windows arena? We haven't been able to get Tinderbox to work for Windows. I don't mind hosting something for Windows to do the tests if that will help. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 24 18:17:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 24 Jul 2009 18:17:29 +0200 Subject: [M3devel] Hudson question In-Reply-To: <4A699EF1.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> Message-ID: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > If we switch to Hudson, does that offer any improvement in the Windows arena? > > We haven't been able to get Tinderbox to work for Windows. > > I don't mind hosting something for Windows to do the tests if that will help. Well, yes and no ;-) Hudson itself should be as easy to install on Windows as on Unix, as it's completely written in Java. You just download the hudson.war file and start it with java -jar hudson.war. Java should be at least a recent 1.6 distribution. You can just try that and play around with the server if you like. The regression test scripts are all written in Bourne shell syntax, so you'd need Cygwin to run those again. There are probably a few quirks left to make them really work on Windows. Perhaps the Interix POSIX environment Jay has told about may be better suited, but I don't know. In the Hudson setup on birch and luthien I've used parts of the regression scripts for Tinderbox. If we want the test scripts to be the same on all systems, it may still be difficult. On the other hand, we could start with a much simpler setup on Windows. Begin with just one test job that checks out and compiles everything. That should be easy to achieve. I don't know if you can use the cmd scripts in Hudson on Windows, but I assume you can. If that works, we could start with transferring your build results to the Hudson server on birch. Or you could allow birch to control your Hudson installation as a slave server. Does that sound feasible? Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 01:12:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:12:30 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: It doesn't likely make a difference. Before you needed Cygwin or Interix. Now you need Cygwin or Interix, and probably Java. Java will probably be a sticking point on various platforms, but the gains are also very nice where it is available. I see there has been work done on an assembly-free Java VM since Sun open sourced their VM, so that promises increased portability. (One wonders some about the Critical Mass VM). Writing more .cmd isn't going to help anything imho. It's just more hard to maintain code that someone will have to maintain in parallel to Olaf's .sh. Which is why I favor Python -- portable, no duplicated effort. "Hard to main" as it, sure, it is easy to get started, but what happens when you decide you need an array, or a hash table? Or any of a number of basic programming constructs? Ok, I guess you have while loops, using goto. Local variables. At least that are strings. Everything is a string. cmd has one or two surprisingly powerfuli features, such as for /f and set /a. If you can't do your work with them, you can't do it. sh is a bit more portable than Python, but not by much and imho at too large a cost in maintainability/generality. It still seems to me like a string based language that can't do much, but I admit I'm not practised in it. (I am very practised in .cmd.) You know, the fact that expression evaluation is in some mix of the "[" command and maybe in sh itself. That people write if xxx true else yyy instead of if not xxx yyy. The fact that Solaris is different. The fact that quoting is needed in various places. Quoting always bothers me. It is hard to predict how many levels of unquoting will be done. I suspect cmd, sh, and Tcl are all in the same overly string based boat. For example in Tcl, { } appear to have the same meaning as in C and C++, good, but in fact they are escape characters, very wierd and bad. Cygwin and Interix both probably work fine. Someone just has to set them up and run them. Consider Cygwin and Interix almost the same. Interix is much faster, if you are calling fork a lot. Cygwin is slightly more compatible with Linux/Posix. Interix has a few ways in which is resembles Linux/Posix more though, such as not using extensions on executables, using ".so", supporting runpath. I think with Cygwin 1.7, both it and Interix go to extreme of supporting backward slash and colon in paths. Interix actually ors in 0xFF00 to such characters but it is transparent to Interix code. Or maybe that's what Cygwin does. I don't remember. It is completely non transparent and discoverable if you look at the results from Win32. Interix probably a larger download, because the part that is mostly "built in" is basically nothing, just some infrastructure and very few utilities. I don't think there is even sh or ksh. Everything else is one large download. On XP nothing is "builtin", there is just one large download. "builtin" is on Server 2003 R2, Vista, Server 2008, etc. (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 18:17:29 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson question > > Quoting Randy Coleburn : > >> Olaf: >> >> If we switch to Hudson, does that offer any improvement in the Windows arena? >> >> We haven't been able to get Tinderbox to work for Windows. >> >> I don't mind hosting something for Windows to do the tests if that will help. > > Well, yes and no ;-) > > Hudson itself should be as easy to install on Windows as on Unix, > as it's completely written in Java. You just download the hudson.war > file and start it with java -jar hudson.war. Java should be at least > a recent 1.6 distribution. You can just try that and play around with > the server if you like. > > The regression test scripts are all written in Bourne shell syntax, > so you'd need Cygwin to run those again. There are probably a few > quirks left to make them really work on Windows. Perhaps the Interix > POSIX environment Jay has told about may be better suited, but I don't > know. > > In the Hudson setup on birch and luthien I've used parts of the > regression scripts for Tinderbox. If we want the test scripts to be > the same on all systems, it may still be difficult. > > On the other hand, we could start with a much simpler setup on Windows. > Begin with just one test job that checks out and compiles everything. > That should be easy to achieve. I don't know if you can use the cmd > scripts in Hudson on Windows, but I assume you can. If that works, > we could start with transferring your build results to the Hudson > server on birch. Or you could allow birch to control your Hudson > installation as a slave server. > > Does that sound feasible? > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sat Jul 25 01:16:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:16:33 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: [truncated as usual..] ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Hudson question > Date: Fri, 24 Jul 2009 23:12:30 +0000 > > > It doesn't likely make a difference. > > > Before you needed Cygwin or Interix. > Now you need Cygwin or Interix, and probably Java. > Java will probably be a sticking point on various platforms, > but the gains are also very nice where it is available. > I see there has been work done on an assembly-free Java VM > since Sun open sourced their VM, so that promises increased portability. > (One wonders some about the Critical Mass VM). > > > Writing more .cmd isn't going to help anything imho. > It's just more hard to maintain code that someone > will have to maintain in parallel to Olaf's .sh. > Which is why I favor Python -- portable, no duplicated effort. > > > "Hard to main" as it, sure, it is easy to get started, but > what happens when you decide you need an array, or a hash table? > Or any of a number of basic programming constructs? > Ok, I guess you have while loops, using goto. > Local variables. At least that are strings. Everything is a string. > cmd has one or two surprisingly powerfuli features, such as for /f > and set /a. If you can't do your work with them, you can't do it. > sh is a bit more portable than Python, but not by much and > imho at too large a cost in maintainability/generality. > It still seems to me like a string based language that can't do much, > but I admit I'm not practised in it. (I am very practised in .cmd.) > > > You know, the fact that expression evaluation is in some mix of the "[" command > and maybe in sh itself. That people write if xxx true else yyy instead > of if not xxx yyy. > The fact that Solaris is different. > The fact that quoting is needed in various places. > Quoting always bothers me. It is hard to predict how many levels > of unquoting will be done. > I suspect cmd, sh, and Tcl are all in the same overly string based boat. > For example in Tcl, { } appear to have the same meaning as in C and C++, good, > but in fact they are escape characters, very wierd and bad. > > > Cygwin and Interix both probably work fine. > Someone just has to set them up and run them. > > > Consider Cygwin and Interix almost the same. > Interix is much faster, if you are calling fork a lot. > Cygwin is slightly more compatible with Linux/Posix. > > > Interix has a few ways in which is resembles Linux/Posix more though, > such as not using extensions on executables, using ".so", supporting > runpath. > > > I think with Cygwin 1.7, both it and Interix go to extreme > of supporting backward slash and colon in paths. > Interix actually ors in 0xFF00 to such characters but > it is transparent to Interix code. Or maybe that's what > Cygwin does. I don't remember. It is completely non > transparent and discoverable if you look at the results from Win32. > > > Interix probably a larger download, because the > part that is mostly "built in" is basically nothing, > just some infrastructure and very few utilities. > I don't think there is even sh or ksh. > Everything else is one large download. > > > On XP nothing is "builtin", there is just one large download. > "builtin" is on Server 2003 R2, Vista, Server 2008, etc. > > > (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. > But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) > > > - Jay > > > ---------------------------------------- >> Date: Fri, 24 Jul 2009 18:17:29 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Hudson question >> >> Quoting Randy Coleburn : >> >>> Olaf: >>> >>> If we switch to Hudson, does that offer any improvement in the Windows arena? >>> >>> We haven't been able to get Tinderbox to work for Windows. >>> >>> I don't mind hosting something for Windows to do the tests if that will help. >> >> Well, yes and no ;-) >> >> Hudson itself should be as easy to install on Windows as on Unix, >> as it's completely written in Java. You just download the hudson.war >> file and start it with java -jar hudson.war. Java should be at least >> a recent 1.6 distribution. You can just try that and play around with >> the server if you like. >> >> The regression test scripts are all written in Bourne shell syntax, >> so you'd need Cygwin to run those again. There are probably a few >> quirks left to make them really work on Windows. Perhaps the Interix >> POSIX environment Jay has told about may be better suited, but I don't >> know. >> >> In the Hudson setup on birch and luthien I've used parts of the >> regression scripts for Tinderbox. If we want the test scripts to be >> the same on all systems, it may still be difficult. >> >> On the other hand, we could start with a much simpler setup on Windows. >> Begin with just one test job that checks out and compiles everything. >> That should be easy to achieve. I don't know if you can use the cmd >> scripts in Hudson on Windows, but I assume you can. If that works, >> we could start with transferring your build results to the Hudson >> server on birch. Or you could allow birch to control your Hudson >> installation as a slave server. >> >> Does that sound feasible? >> >> Regards, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sat Jul 25 01:18:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:18:17 +0000 Subject: [M3devel] FW: Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: [truncated again, one more try then I give up..] > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] Hudson question >> Date: Fri, 24 Jul 2009 23:12:30 +0000 >> >> >> It doesn't likely make a difference. >> >> >> Before you needed Cygwin or Interix. >> Now you need Cygwin or Interix, and probably Java. >> Java will probably be a sticking point on various platforms, >> but the gains are also very nice where it is available. >> I see there has been work done on an assembly-free Java VM >> since Sun open sourced their VM, so that promises increased portability. >> (One wonders some about the Critical Mass VM). >> >> >> Writing more .cmd isn't going to help anything imho. >> It's just more hard to maintain code that someone >> will have to maintain in parallel to Olaf's .sh. >> Which is why I favor Python -- portable, no duplicated effort. >> >> >> "Hard to main" as it, sure, it is easy to get started, but >> what happens when you decide you need an array, or a hash table? >> Or any of a number of basic programming constructs? >> Ok, I guess you have while loops, using goto. >> Local variables. At least that are strings. Everything is a string. >> cmd has one or two surprisingly powerfuli features, such as for /f >> and set /a. If you can't do your work with them, you can't do it. >> sh is a bit more portable than Python, but not by much and >> imho at too large a cost in maintainability/generality. >> It still seems to me like a string based language that can't do much, >> but I admit I'm not practised in it. (I am very practised in .cmd.) >> >> >> You know, the fact that expression evaluation is in some mix of the "[" command >> and maybe in sh itself. That people write if xxx true else yyy instead >> of if not xxx yyy. >> The fact that Solaris is different. >> The fact that quoting is needed in various places. >> Quoting always bothers me. It is hard to predict how many levels >> of unquoting will be done. >> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >> but in fact they are escape characters, very wierd and bad. >> >> >> Cygwin and Interix both probably work fine. >> Someone just has to set them up and run them. >> >> >> Consider Cygwin and Interix almost the same. >> Interix is much faster, if you are calling fork a lot. >> Cygwin is slightly more compatible with Linux/Posix. >> >> >> Interix has a few ways in which is resembles Linux/Posix more though, >> such as not using extensions on executables, using ".so", supporting >> runpath. >> >> >> I think with Cygwin 1.7, both it and Interix go to extreme >> of supporting backward slash and colon in paths. >> Interix actually ors in 0xFF00 to such characters but >> it is transparent to Interix code. Or maybe that's what >> Cygwin does. I don't remember. It is completely non >> transparent and discoverable if you look at the results from Win32. >> >> >> Interix probably a larger download, because the >> part that is mostly "built in" is basically nothing, >> just some infrastructure and very few utilities. >> I don't think there is even sh or ksh. >> Everything else is one large download. >> >> >> On XP nothing is "builtin", there is just one large download. >> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >> >> >> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >> >> >> - Jay >> >> >> ---------------------------------------- [deliberate snip] From jay.krell at cornell.edu Sat Jul 25 01:30:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 24 Jul 2009 23:30:23 +0000 Subject: [M3devel] Hudson question In-Reply-To: <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: Interix is actually multiple downloads. The first one has a lot of bugs, like gcc never working on systems that support the "no execute" bit, and the NFS server or client crashing the machine (bugcheck, blue screen). To get updates, instead of the usual windowsupdate.microsoft.com, you have to go a special web page, type in the KB articles that you discover searching the web, recieve a link to a password-protected executable/.zip, you get the current password and the next one. If you wait too long, or gosh, want to reinstall everything, officially you need to go through the ridiculuous rigamarole again. Though actually what you can do is extract the .exes/.zips once and keep those around. The first large download from Microsoft gives you a bunch of "utilities", like sh, ksh, gcc, ld, bash. There is also a large second download from interopsystems.com or such to get more and updated utilities. That's where I got e.g. Python. There is a small problem compiling Python out of the box, something around filesystem case sensitivity, even though Interix does offer case sensitive file system, there seems to be a small problem with it. Python detects the case sensitive file system, in which case it is willing to put Python directory and python executable file next to each other, but when it later runs "sh -c ./python", that tries to run the directory and gets access denied. There is a code path in configure for case insensitive, which alters the paths, presumably the workaround is to set the environment variable to force the configure check. Heck, they could just always do it that way.. Presumably starting with a base of Server 2003 R2 or Vista or newer is better, but the above is the experience on XP. So, it is kind of a pain on XP, but the result is way way faster than Cygwin. The cost of fork on Cygwin is huge and definitely occurs. I'm still in the habit of using Cygwin though, like for cvs. Cygwin is multiple downloads in a sense, but they have a fairly nice setup that will do them all. I think the interopsystems.com download does lead pretty directly to X Windows too via a separate package. I just have to remind folks that if the main goal is just forward slashes in file system paths, NT386 works fine there now. Granted, I understand, you also want sh, X windows, 64bit LONGINT, optimizing backend backend (MinGW can deliver the last two). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: FW: [M3devel] Hudson question > Date: Fri, 24 Jul 2009 23:18:17 +0000 > > > [truncated again, one more try then I give up..] > >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>> Subject: RE: [M3devel] Hudson question >>> Date: Fri, 24 Jul 2009 23:12:30 +0000 >>> >>> >>> It doesn't likely make a difference. >>> >>> >>> Before you needed Cygwin or Interix. >>> Now you need Cygwin or Interix, and probably Java. >>> Java will probably be a sticking point on various platforms, >>> but the gains are also very nice where it is available. >>> I see there has been work done on an assembly-free Java VM >>> since Sun open sourced their VM, so that promises increased portability. >>> (One wonders some about the Critical Mass VM). >>> >>> >>> Writing more .cmd isn't going to help anything imho. >>> It's just more hard to maintain code that someone >>> will have to maintain in parallel to Olaf's .sh. >>> Which is why I favor Python -- portable, no duplicated effort. >>> >>> >>> "Hard to main" as it, sure, it is easy to get started, but >>> what happens when you decide you need an array, or a hash table? >>> Or any of a number of basic programming constructs? >>> Ok, I guess you have while loops, using goto. >>> Local variables. At least that are strings. Everything is a string. >>> cmd has one or two surprisingly powerfuli features, such as for /f >>> and set /a. If you can't do your work with them, you can't do it. >>> sh is a bit more portable than Python, but not by much and >>> imho at too large a cost in maintainability/generality. >>> It still seems to me like a string based language that can't do much, >>> but I admit I'm not practised in it. (I am very practised in .cmd.) >>> >>> >>> You know, the fact that expression evaluation is in some mix of the "[" command >>> and maybe in sh itself. That people write if xxx true else yyy instead >>> of if not xxx yyy. >>> The fact that Solaris is different. >>> The fact that quoting is needed in various places. >>> Quoting always bothers me. It is hard to predict how many levels >>> of unquoting will be done. >>> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >>> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >>> but in fact they are escape characters, very wierd and bad. >>> >>> >>> Cygwin and Interix both probably work fine. >>> Someone just has to set them up and run them. >>> >>> >>> Consider Cygwin and Interix almost the same. >>> Interix is much faster, if you are calling fork a lot. >>> Cygwin is slightly more compatible with Linux/Posix. >>> >>> >>> Interix has a few ways in which is resembles Linux/Posix more though, >>> such as not using extensions on executables, using ".so", supporting >>> runpath. >>> >>> >>> I think with Cygwin 1.7, both it and Interix go to extreme >>> of supporting backward slash and colon in paths. >>> Interix actually ors in 0xFF00 to such characters but >>> it is transparent to Interix code. Or maybe that's what >>> Cygwin does. I don't remember. It is completely non >>> transparent and discoverable if you look at the results from Win32. >>> >>> >>> Interix probably a larger download, because the >>> part that is mostly "built in" is basically nothing, >>> just some infrastructure and very few utilities. >>> I don't think there is even sh or ksh. >>> Everything else is one large download. >>> >>> >>> On XP nothing is "builtin", there is just one large download. >>> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >>> >>> >>> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >>> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- > [deliberate snip] > From rcoleburn at scires.com Sat Jul 25 02:43:13 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 24 Jul 2009 20:43:13 -0400 Subject: [M3devel] FW: Hudson question In-Reply-To: References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> Message-ID: <4A6A1C90.1E75.00D7.1@scires.com> Jay: I know you are pro Python and some scripts are in python and some scripts are in .sh and there is cygwin etc etc, but let me list why I think we need CMD on Windows: 1. CMD comes with Windows out-of-the-box. No extra config/install is required. 2. I want to be able to launch a CMD window and use the cm3 command line tools to build Modula-3 packages. I also want to be able to run Modula-3 programs without need of any other tools except what comes with Windows by default. Now the latter isn't exactly possible if you are dependent on the .NET framework, but most systems have .NET anyway because Microsoft has pushed it out through online updates. 3. I continue to experience problems with cygwin, python, etc. because the setup in each is slightly different and there are dependencies that are not obvious. If you succeed in installing cm3 using cygwin, it isn't always possible to build/run packages from CMD. I haven't been able to get the python scripts to work for me, despite installing python. 4. CM3IDE launches the native shell to run the cm3 command line tools. On Windows, this shell is CMD. We need to preserve this functionality. 5. I have provided various CMD scripts in the repository and I've been keeping these up-to-date. I don't mind continuing to do this. 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. 7. Whatever automated test environment we provide on Windows must work in the native shell in order to prove that stuff is working in that shell. If you use cygwin or some other shell, that doesn't mean it will work in CMD. Regards, Randy Coleburn >>> Jay K 7/24/2009 7:18 PM >>> [truncated again, one more try then I give up..] > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] Hudson question >> Date: Fri, 24 Jul 2009 23:12:30 +0000 >> >> >> It doesn't likely make a difference. >> >> >> Before you needed Cygwin or Interix. >> Now you need Cygwin or Interix, and probably Java. >> Java will probably be a sticking point on various platforms, >> but the gains are also very nice where it is available. >> I see there has been work done on an assembly-free Java VM >> since Sun open sourced their VM, so that promises increased portability. >> (One wonders some about the Critical Mass VM). >> >> >> Writing more .cmd isn't going to help anything imho. >> It's just more hard to maintain code that someone >> will have to maintain in parallel to Olaf's .sh. >> Which is why I favor Python -- portable, no duplicated effort. >> >> >> "Hard to main" as it, sure, it is easy to get started, but >> what happens when you decide you need an array, or a hash table? >> Or any of a number of basic programming constructs? >> Ok, I guess you have while loops, using goto. >> Local variables. At least that are strings. Everything is a string. >> cmd has one or two surprisingly powerfuli features, such as for /f >> and set /a. If you can't do your work with them, you can't do it. >> sh is a bit more portable than Python, but not by much and >> imho at too large a cost in maintainability/generality. >> It still seems to me like a string based language that can't do much, >> but I admit I'm not practised in it. (I am very practised in .cmd.) >> >> >> You know, the fact that expression evaluation is in some mix of the "[" command >> and maybe in sh itself. That people write if xxx true else yyy instead >> of if not xxx yyy. >> The fact that Solaris is different. >> The fact that quoting is needed in various places. >> Quoting always bothers me. It is hard to predict how many levels >> of unquoting will be done. >> I suspect cmd, sh, and Tcl are all in the same overly string based boat. >> For example in Tcl, { } appear to have the same meaning as in C and C++, good, >> but in fact they are escape characters, very wierd and bad. >> >> >> Cygwin and Interix both probably work fine. >> Someone just has to set them up and run them. >> >> >> Consider Cygwin and Interix almost the same. >> Interix is much faster, if you are calling fork a lot. >> Cygwin is slightly more compatible with Linux/Posix. >> >> >> Interix has a few ways in which is resembles Linux/Posix more though, >> such as not using extensions on executables, using ".so", supporting >> runpath. >> >> >> I think with Cygwin 1.7, both it and Interix go to extreme >> of supporting backward slash and colon in paths. >> Interix actually ors in 0xFF00 to such characters but >> it is transparent to Interix code. Or maybe that's what >> Cygwin does. I don't remember. It is completely non >> transparent and discoverable if you look at the results from Win32. >> >> >> Interix probably a larger download, because the >> part that is mostly "built in" is basically nothing, >> just some infrastructure and very few utilities. >> I don't think there is even sh or ksh. >> Everything else is one large download. >> >> >> On XP nothing is "builtin", there is just one large download. >> "builtin" is on Server 2003 R2, Vista, Server 2008, etc. >> >> >> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000. >> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?) >> >> >> - Jay >> >> >> ---------------------------------------- [deliberate snip] CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jul 25 03:28:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:28:13 +0000 Subject: [M3devel] FW: Hudson question In-Reply-To: <4A6A1C90.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> <4A6A1C90.1E75.00D7.1@scires.com> Message-ID: > 1. CMD comes with Windows out-of-the-box. No extra config/install is required. So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate. > 2. I want to be able to launch a CMD window and use the cm3 command line tools > to build Modula-3 packages. > I also want to be able to run Modula-3 programs without need of > any other tools except what comes with Windows by default. Now the > latter isn't exactly possible if you are dependent on Agreed and not necessarily contradicted. You need CVS to get the current Modula-3 source, but not to use it. Where is the line? > the .NET framework, but most systems have .NET anyway because Microsoft > has pushed it out through online updates. How is the .NET framework relevant? > 3. I continue to experience problems with cygwin, python, etc. because the setup in > each is slightly different and there are dependencies that are not obvious. Let's work on this? What are the errors? I've installed them each many times on many computers with no problem. One problem you might hit is that you might have both Cygwin and native Python. Start out with just one or the other. > If you succeed in installing cm3 using cygwin, it isn't always possible to build/run > packages from CMD. Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH. However the use of sh is separate from the use of the NT386GNU platform. You can launch native NT386 cm3.exe from Cygwin sh. If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency. > I haven't been able to get the python scripts to work for me, despite installing python. Let's work on that? > 4. CM3IDE launches the native shell to run the cm3 command line tools. > On Windows, this shell is CMD. We need to preserve this functionality. There is no need for CM3IDE to launch any shell at all. Why does it? You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used. Just because a console app runs or a console window comes up, does not imply cmd is anywhere. You do need a cmd wrapper if you use, e.g. redirection, on the command line. Things like system() tend to use cmd. And the Modula-3 wrapper libraries might use cmd. But you really don't need any shell at all. I would not advocate any sh or Python wrapping. Adding sh really slow things down. Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection. > 5. I have provided various CMD scripts in the repository and I've been > keeping these up-to-date. I don't mind continuing to do this. And the Tinderbox and Hudson stuff? I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language. I also haven't (and might not) finished dupliating the .sh. I'm not sure. You know, "soon" I should try one or more of: Old Tinderbox/sh stuff on Windows. New Hudson/sh stuff on Windows. Either of above but having rewritten .sh in .cmd or py. Basically the story was, I was on vacation with a Mac. I needed/wanted changes to the .sh but was unwilling to work on .sh. It is cryptic and despite years of slightly trying, I can't seem to get the hang of it. And then I fear that anything I write will only work one OS. I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few. I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed. > 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. I commited working automation to build an .msi. It could use some polish though. The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3. I investigated a number of options for how to build the setup. I had never previously built an .msi, nor it follows, used Wix. I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner. I can detail what I remember of my experiences. IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files. Another .msi builder was and still is promising. NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience. I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running. > 7. Whatever automated test environment we provide on Windows must work in the > native shell in order to prove that stuff is working in that shell. If you use cygwin > or some other shell, that doesn't mean it will work in CMD. That is a fine line. Not necessarily true, but easier to prove true the other way around, granted. If you don't use Cygwin at all, then definitely the stuff works without Cygwin. If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it. But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script). Do the tests work outside Hudson? Outside Tinderbox? Well, it is not too difficult to run them outside either. Do they work outside the .cmd wrappers? Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake? Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening". Modula-3 is obviously general purpose. :) This dichotomy between "scripting" and non-scripting languages has long bugged me. The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate. I understand the guidance -- "pick the right tool for the job". But there is also guidance -- "don't have too many different tools; don't have a different tool for each job". If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving???? Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc... - Jay From jay.krell at cornell.edu Sat Jul 25 03:40:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:40:38 +0000 Subject: [M3devel] which new platforms do people want? Message-ID: Other than finishing ARM_DARWIN, what platforms are people interested in? And will actually use?? I have /many/ to choice from, via both virtual x86/AMD64 machines and available hardware. Some of these are started but didn't get as far yet as having archives uploaded. I386,AMD64_SOLARIS, NETBSD, OPENBSD (all started and mostly easy, will try to finish these up soon) Alpha of anything (VMS, Linux, *BSD, Tru64) AMD64_NT if MinGW is in good enough shape PPC_NETBSD (should be easy) PPC_FREEBSD (slightly hard to setup) Irix 32bit and 64bit AIX 32bit and 64bit HP-UX PA64 and IA64 (PA32 already in good shape) IA64 of anything (VMS, HP-UX, Linux, *BSD; Linux being the one I have up/running) MIPS of anything (Irix, Linux, *BSD (started)) ARM_LINUX PPC64_DARWIN, LINUX MSDOS/DJGPP (appears to have the timer support for user threads) PPC_MACOS, M68K_MACOS Plan9 (unlikely, uses old gcc fork, best handled with a C backend) Beos (unlikely, not very VM-compatible) DragonflyBSD (VM) WinCE (unlikely, no hardware) ? A C backend could serve pretty much anything. We could likely have C_WIN32 and C_POSIX and nearly all porting work declared done, just two distribution archives, if that. Of course then the "fun" of installing all these systems would be lost. :) I think I can knock off I386,AMD64_SOLARIS, NetBSD, OpenBSD, then try out more esoteric stuff like Alpha and MIPS and then IA64. My $50 network router runs Linux 2.4 on 32bit MIPS, I think with uclibc. It is low end for sure, but has SMB client builtin, so infinite diskspace. I have a network attached hard drive running Linux 2.6 on ARM, with uclibc. uclibc imho threatens our naming conventions, unless we target the Linux kernel instead of libc, which I think is maybe a good idea. Linux 2.4 also treatens the naming convention perhaps. I thought it was long gone but it isn't. Current "distributions" for network routers use it. Maybe there should be MIPS_LINUX_USERTHREADS? Maybe *_USERTHREADS in general, where it works and people will use it? - Jay From jay.krell at cornell.edu Sat Jul 25 03:42:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 01:42:04 +0000 Subject: [M3devel] FW: FW: Hudson question In-Reply-To: <4A6A1C90.1E75.00D7.1@scires.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> <4A699EF1.1E75.00D7.1@scires.com> <20090724181729.qtlne24z4o8kog88@mail.elegosoft.com> <4A6A1C90.1E75.00D7.1@scires.com> Message-ID: [truncated again] ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Hudson question > Date: Sat, 25 Jul 2009 01:28:13 +0000 > > >> 1. CMD comes with Windows out-of-the-box. No extra config/install is required. > > > So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate. > > >> 2. I want to be able to launch a CMD window and use the cm3 command line tools >> to build Modula-3 packages. >> I also want to be able to run Modula-3 programs without need of >> any other tools except what comes with Windows by default. Now the >> latter isn't exactly possible if you are dependent on > > > Agreed and not necessarily contradicted. > You need CVS to get the current Modula-3 source, but not to use it. > Where is the line? > > >> the .NET framework, but most systems have .NET anyway because Microsoft >> has pushed it out through online updates. > > How is the .NET framework relevant? > > >> 3. I continue to experience problems with cygwin, python, etc. because the setup in >> each is slightly different and there are dependencies that are not obvious. > > > Let's work on this? What are the errors? I've installed them each many times on many computers with no problem. > One problem you might hit is that you might have both Cygwin and native Python. > Start out with just one or the other. > > >> If you succeed in installing cm3 using cygwin, it isn't always possible to build/run >> packages from CMD. > > > Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH. > > > However the use of sh is separate from the use of the NT386GNU platform. > You can launch native NT386 cm3.exe from Cygwin sh. > If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency. > > >> I haven't been able to get the python scripts to work for me, despite installing python. > > > Let's work on that? > > >> 4. CM3IDE launches the native shell to run the cm3 command line tools. >> On Windows, this shell is CMD. We need to preserve this functionality. > > There is no need for CM3IDE to launch any shell at all. > Why does it? > You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used. > Just because a console app runs or a console window comes up, does not imply cmd is anywhere. > You do need a cmd wrapper if you use, e.g. redirection, on the command line. > Things like system() tend to use cmd. > And the Modula-3 wrapper libraries might use cmd. > But you really don't need any shell at all. > > > I would not advocate any sh or Python wrapping. Adding sh really slow things down. > > > Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection. > > >> 5. I have provided various CMD scripts in the repository and I've been >> keeping these up-to-date. I don't mind continuing to do this. > > And the Tinderbox and Hudson stuff? > I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language. > I also haven't (and might not) finished dupliating the .sh. > I'm not sure. > You know, "soon" I should try one or more of: > Old Tinderbox/sh stuff on Windows. > New Hudson/sh stuff on Windows. > Either of above but having rewritten .sh in .cmd or py. > > > Basically the story was, I was on vacation with a Mac. > I needed/wanted changes to the .sh but was unwilling to work on .sh. > It is cryptic and despite years of slightly trying, I can't seem to get the hang of it. > And then I fear that anything I write will only work one OS. > I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few. > > I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed. > > >> 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here. > > > I commited working automation to build an .msi. > It could use some polish though. > The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3. > > > I investigated a number of options for how to build the setup. > I had never previously built an .msi, nor it follows, used Wix. > I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner. > I can detail what I remember of my experiences. > IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files. > Another .msi builder was and still is promising. > NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience. > > > I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running. > > >> 7. Whatever automated test environment we provide on Windows must work in the >> native shell in order to prove that stuff is working in that shell. If you use cygwin >> or some other shell, that doesn't mean it will work in CMD. > > > That is a fine line. > Not necessarily true, but easier to prove true the other way around, granted. > If you don't use Cygwin at all, then definitely the stuff works without Cygwin. > If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it. > > But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script). > > Do the tests work outside Hudson? Outside Tinderbox? > Well, it is not too difficult to run them outside either. > Do they work outside the .cmd wrappers? > > Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake? > Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening". > > > Modula-3 is obviously general purpose. :) > > > This dichotomy between "scripting" and non-scripting languages has long bugged me. > The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate. > > I understand the guidance -- "pick the right tool for the job". > But there is also guidance -- "don't have too many different tools; don't have a different tool for each job". > > If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving???? > Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc... > > > - Jay > From jay.krell at cornell.edu Sat Jul 25 04:06:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 02:06:14 +0000 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: It seems the Tinderbox stuff always keeps around ~/work/cm3-ws/datetime, one for each run? I see them accumulating on my machines. Can you send me/all your exact cron entries? For Tinderbox and Hudson? Even what file they are in? And how cron is enabled in /etc? Just in case? Thanks. - Jay ---------------------------------------- > Date: Fri, 24 Jul 2009 11:44:38 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: Hudson errors out of diskspace > > Quoting Jay K : > >> Here's another: >> >> new source -> compiling ../FreeBSD4/cm3unix.c >> ../FreeBSD4/cm3unix.c:3: fatal error: error writing to >> /var/tmp/ccVwJXWF.s: No space left on device > > That was on my home machine because core dumps from m3tests were > accumulating in /var/tmp. I've now set the core dump limit to 0 > for those jobs. > >> Hudson is looking like a big improvement though -- the last success, >> last failure columns, the list of changes in a build, the quick >> access to the full output. > > Yes. I've been using it for about half a year now, and apart from the > fact that it's resource hungry and sometimes slow, it's easy to use > and configure. And you find a plug-in for almost everything. > > Since yesterday afternoon all necessary plug-ins for interaction > with other servers should be installed. > > I've just moved the crontab jobs from user m3 on birch to hudson, > see http://hudson.modula3.com:8080/view/m3-www-support/. > > My network connection is very unstable currently, so more failures > are to be expected. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Sat Jul 25 13:54:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 13:54:36 +0200 Subject: [M3devel] Hudson errors out of diskspace In-Reply-To: References: <20090724114438.swos35v9z4wsw4sw@mail.elegosoft.com> Message-ID: <20090725135436.4frp8e0c8w8ckgg4@mail.elegosoft.com> Quoting Jay K : > It seems the Tinderbox stuff always keeps around > ~/work/cm3-ws/datetime, one for each run? > I see them accumulating on my machines. Use cleanup_all from scripts/regression/defs.sh. > Can you send me/all your exact cron entries? > For Tinderbox and Hudson? Hudson doesn't have any crontab. It implements cron functionality itself. > Even what file they are in? I don't know where personal crontab files are kept (probably implementation dependent). You just use the crontab command to access them. > And how cron is enabled in /etc? Just in case? I don't think there is any system-independent way to enable cron. Just run the daemon from one of the system startup scripts (/etc/rc or /etc/rc.d/*). > Thanks. Here's the crontab of m3 on birch. Everything is disabled now (moved to Hudson). I'll add some remarks with -->. m3 at birch:~$ crontab -l MAILTO=m3-support at elego.de TESTHOSTNAME=birch.elegosoft.com ### Note: all these crontab jobs have been moved to the CM3 hudson instance on birch # m h dom mon dow command --> crontabs residing in /etc will likely have another field for the user: --> # m h dom mon dow user command #0 2,14 * * * cd ~/cm3 && BUILD_REL=lastok ./tinderbox-build.sh cm3.build >/dev/null #0 4,16 * * * cd ~/cm3 && ./tinderbox-build.sh cm3.build >/dev/null --> These were the release-build and last-ok build when LINUXLIBC6 was --> the target on birch #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_pkg_status.sh #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_m3tests.sh #*/30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_snapshot_status.sh #*/30 * * * * ${HOME}/bin/update_changelog.sh #*/30 * * * * cd /var/www/modula3.elegosoft.com/cm3/uploaded-archives && ./update_download_index.sh #5 7 * * * cd /var/www/modula3.elegosoft.com/cm3/ && make all >/dev/null --> old WWW service entries before the crash # This should work ### 0 14 * * * cd ~/cm3 && BUILD_REL=lastok ./tinderbox-build.sh cm3.build >/dev/null 2>&1 --> This was run till yesterday, but with additional tests in cm3.build # Cannot work, no release archives for AMD64_LINUX #0 4,16 * * * cd ~/cm3 && ./tinderbox-build.sh cm3.build >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_pkg_status.sh >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_m3tests.sh >/dev/null 2>&1 ### */30 * * * * cd ~/cm3 && ./cm3/scripts/regression/update_snapshot_status.sh >/dev/null 2>&1 ### */60 * * * * ${HOME}/bin/update_changelog.sh >/dev/null 2>&1 ### */30 * * * * cd /var/www/modula3.elegosoft.com/cm3/uploaded-archives && ./update_download_index.sh >/dev/null 2>&1 ### 5 7 * * * cd /var/www/modula3.elegosoft.com/cm3/ && make all >/dev/null >/dev/null 2>&1 --> entries inserted after the crash, when nothing was working correctly... Does that help? If you can run Hudson on any of your systems, I wouldn't bother with cron. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 16:58:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 09:58:24 -0500 Subject: [M3devel] Fwd: Output from "cron" command References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> Message-ID: <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> This is an old error for Solaris that I fixed a long time ago. Can someone restore? Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: July 25, 2009 5:30:35 AM CDT > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > U regression-scripts/defs.sh > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.07.25 06:30:23 -- checkout in progress. > [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is not > of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set > incorrectly, or the mail was delayed for a long time. > variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.07.25 06:30:32 -- checkout in progress. > [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is not > of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set > incorrectly, or the mail was delayed for a long time. > variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 20:00:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:00:26 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> Message-ID: <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> Quoting Tony Hosking : > This is an old error for Solaris that I fixed a long time ago. Can > someone restore? Hi Tony, as far as I can see nothing has changed regarding STARTTIME: > % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME|date' Annotations for scripts/regression/tinderbox-build.sh *************** 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date '+%Y%m%d-%H%M%S'`" 1.8 (wagner 03-Feb-08): STARTTIME="$4" 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z "${BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] 1.8 (wagner 03-Feb-08): echo " date 'date +%s'" 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date +%s` 1.8 (wagner 03-Feb-08): tinderbox_header "${TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." 1.10 (hosking 09-Mar-08): echo "[start checkout `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end checkout `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- compile in progress." 1.10 (hosking 09-Mar-08): echo "[start compile `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- tests in progress." 1.10 (hosking 09-Mar-08): echo "[start run-tests `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "[end run-tests `date '+%Y.%m.%d %H:%M:%S'`]" 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." Nothing at all has changed in these scripts in July: % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 Annotations for scripts/regression/tinderbox-build.sh *************** luthien [~/work/cm3] wagner % cvs ann scripts/regression/cm3.bu | egrep Jul-09 cm3.build cm3.build~ luthien [~/work/cm3] wagner % cvs ann scripts/regression/cm3.build | egrep Jul-09 Annotations for scripts/regression/cm3.build *************** luthien [~/work/cm3] wagner Perhaps I'm looking for the wrong thing. What exactly did you change long ago to make it work? I'm at a loss now. > Sent from my iPhone You seem to be very `mobile' lately ;-) > Begin forwarded message: > >> From: Tony Hosking >> Date: July 25, 2009 5:30:35 AM CDT >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> > >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> U regression-scripts/defs.sh >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.07.25 06:30:23 -- checkout in progress. >> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is not >> of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set >> incorrectly, or the mail was delayed for a long time. >> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >> >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.07.25 06:30:32 -- checkout in progress. >> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is not >> of the form MM/DD/YY HH:MM:SS, or unix date, or your clock is set >> incorrectly, or the mail was delayed for a long time. >> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >> >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Jul 25 20:10:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:10:52 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc Message-ID: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> We've got two failures for package tests on birch that don't show up on FreeBSD: http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ I think Jay already mentioned that there might be a conflict. Any objections to rename the m3 library? I think I'll just try it and see what happens... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 20:12:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 18:12:19 +0000 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: I thought I already renamed it but maybe I messed up or maybe the report is old? - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 20:10:52 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] package test failures on birch: duplicate libodbc > > We've got two failures for package tests on birch that don't show up > on FreeBSD: > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ > > I think Jay already mentioned that there might be a conflict. > > Any objections to rename the m3 library? > > I think I'll just try it and see what happens... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Sat Jul 25 20:16:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:16:55 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: <20090725201655.030d1ygif4cgksg4@mail.elegosoft.com> Quoting Jay K : > I thought I already renamed it but maybe I messed up or maybe the > report is old? I just found out you had, too. The report is not old. Perhaps we need to remove old libs manually which are still left in /usr/local/cm3/lib? I'll try that... Olaf > > - Jay > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:10:52 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] package test failures on birch: duplicate libodbc >> >> We've got two failures for package tests on birch that don't show up >> on FreeBSD: >> >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >> >> I think Jay already mentioned that there might be a conflict. >> >> Any objections to rename the m3 library? >> >> I think I'll just try it and see what happens... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 20:15:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 18:15:14 +0000 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: Hm, maybe the problem is that shipping should delete the old files? Should I add something called, like install_delete_file? delete_installed_file?? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 25 Jul 2009 18:12:19 +0000 > Subject: Re: [M3devel] package test failures on birch: duplicate libodbc > > > I thought I already renamed it but maybe I messed up or maybe the report is old? > > - Jay > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:10:52 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] package test failures on birch: duplicate libodbc >> >> We've got two failures for package tests on birch that don't show up >> on FreeBSD: >> >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >> >> I think Jay already mentioned that there might be a conflict. >> >> Any objections to rename the m3 library? >> >> I think I'll just try it and see what happens... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sat Jul 25 20:27:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:27:10 +0200 Subject: [M3devel] package test failures on birch: duplicate libodbc In-Reply-To: References: <20090725201052.d9bizjc6g4skowcg@mail.elegosoft.com> Message-ID: <20090725202710.xq62yw55c848o8g4@mail.elegosoft.com> Quoting Jay K : > Hm, maybe the problem is that shipping should delete the old files? > > Should I add something called, like install_delete_file? > delete_installed_file?? No, this is a migration problem that cannot be solved by the build tooling without being aware of all the history. I just removed all cm3 libodbc.so files on birch (except those in your home). If the tests succeed now, we can forget about it. Olaf > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Date: Sat, 25 Jul 2009 18:12:19 +0000 >> Subject: Re: [M3devel] package test failures on birch: duplicate libodbc >> >> >> I thought I already renamed it but maybe I messed up or maybe the >> report is old? >> >> - Jay >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:10:52 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] package test failures on birch: duplicate libodbc >>> >>> We've got two failures for package tests on birch that don't show up >>> on FreeBSD: >>> >>> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/ >>> http://hudson.modula3.com:8080/view/cm3/job/cm3-test-all-pkgs-AMD64_LINUX/52/testReport/(root)/CM3%20package%20tests%20status/m3_db_odbc_tests/ >>> >>> I think Jay already mentioned that there might be a conflict. >>> >>> Any objections to rename the m3 library? >>> >>> I think I'll just try it and see what happens... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 20:32:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 14:32:08 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> Message-ID: <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> Perhaps I am confusing with the original change I made for 1.10 to the parameter to the "date" command. In any case, something changed so that my scripts did not run properly. It's been a long time since I've seen a sane tinderbox run for Solaris -- will things be stabilising soon? -- Tony (not mobile) On 25 Jul 2009, at 14:00, Olaf Wagner wrote: > Quoting Tony Hosking : > >> This is an old error for Solaris that I fixed a long time ago. Can >> someone restore? > > Hi Tony, > > as far as I can see nothing has changed regarding STARTTIME: > > >> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| >> date' > > Annotations for scripts/regression/tinderbox-build.sh > *************** > 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date '+%Y > %m%d-%H%M%S'`" > 1.8 (wagner 03-Feb-08): STARTTIME="$4" > 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z "$ > {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] > 1.8 (wagner 03-Feb-08): echo > " date 'date +%s'" > 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: > $STARTTIME > 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + > %s` > 1.8 (wagner 03-Feb-08): tinderbox_header "$ > {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" > 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- checkout in progress." > 1.10 (hosking 09-Mar-08): echo "[start checkout `date '+ > %Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end checkout `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- compile in progress." > 1.10 (hosking 09-Mar-08): echo "[start compile `date '+ > %Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- tests in progress." > 1.10 (hosking 09-Mar-08): echo "[start run-tests `date > '+%Y.%m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "[end run-tests `date '+%Y. > %m.%d %H:%M:%S'`]" > 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: > %S'` -- checkout, compile and test run done." > > Nothing at all has changed in these scripts in July: > > % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 > > Annotations for scripts/regression/tinderbox-build.sh > *************** > luthien [~/work/cm3] wagner > % cvs ann scripts/regression/cm3.bu | egrep Jul-09 > cm3.build cm3.build~ > luthien [~/work/cm3] wagner > % cvs ann scripts/regression/cm3.build | egrep Jul-09 > > Annotations for scripts/regression/cm3.build > *************** > luthien [~/work/cm3] wagner > > > Perhaps I'm looking for the wrong thing. What exactly did you change > long ago to make it work? I'm at a loss now. > >> Sent from my iPhone > > You seem to be very `mobile' lately ;-) > > >> Begin forwarded message: >> >>> From: Tony Hosking >>> Date: July 25, 2009 5:30:35 AM CDT >>> To: hosking at cs.purdue.edu >>> Subject: Output from "cron" command >>> >> >>> Your "cron" job on niagara.cs.purdue.edu >>> $HOME/cm3/scripts/regression/cron.sh >>> >>> produced the following output: >>> >>> U regression-scripts/defs.sh >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>> >>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.07.25 06:30:23 -- checkout in progress. >>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>> is set incorrectly, or the mail was delayed for a long time. >>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>> >>> Error: Sending buildlog failed! >>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>> >>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.07.25 06:30:32 -- checkout in progress. >>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>> is set incorrectly, or the mail was delayed for a long time. >>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>> minutes) >>> >>> Error: Sending buildlog failed! >>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 20:44:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 20:44:38 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> Message-ID: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Quoting Tony Hosking : > Perhaps I am confusing with the original change I made for 1.10 to the > parameter to the "date" command. > > In any case, something changed so that my scripts did not run > properly. It's been a long time since I've seen a sane tinderbox run > for Solaris -- will things be stabilising soon? I broke the last one yesterday with $() (fixed soon afterwards), but the one before succeeded: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 I was hoping to get a green build from one of your systems today (big-endian, different architecture) to finally fix the RC2 tag. But if you cannot send your results to the tinderbox that will be difficult :-/ I really don't understand why that should have stopped working. The error below seems to be that the reported start time is 0, and that cannot be according to the source. Could you set -x at the start of the tinderbox script and try again? Jay, can you think of anything you have changed that may cause Tony's problem? Olaf > -- Tony (not mobile) :-) > On 25 Jul 2009, at 14:00, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> This is an old error for Solaris that I fixed a long time ago. Can >>> someone restore? >> >> Hi Tony, >> >> as far as I can see nothing has changed regarding STARTTIME: >> >> >>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >> >> Annotations for scripts/regression/tinderbox-build.sh >> *************** >> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >> '+%Y %m%d-%H%M%S'`" >> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >> 1.8 (wagner 03-Feb-08): echo " >> date 'date +%s'" >> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >> %S'` -- checkout in progress." >> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >> '+ %Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >> '+%Y. %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >> %H:%M: %S'` -- compile in progress." >> 1.10 (hosking 09-Mar-08): echo "[start compile `date >> '+ %Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >> %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >> %H:%M: %S'` -- tests in progress." >> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >> '+%Y.%m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >> '+%Y. %m.%d %H:%M:%S'`]" >> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >> %S'` -- checkout, compile and test run done." >> >> Nothing at all has changed in these scripts in July: >> >> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >> >> Annotations for scripts/regression/tinderbox-build.sh >> *************** >> luthien [~/work/cm3] wagner >> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >> cm3.build cm3.build~ >> luthien [~/work/cm3] wagner >> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >> >> Annotations for scripts/regression/cm3.build >> *************** >> luthien [~/work/cm3] wagner >> >> >> Perhaps I'm looking for the wrong thing. What exactly did you change >> long ago to make it work? I'm at a loss now. >> >>> Sent from my iPhone >> >> You seem to be very `mobile' lately ;-) >> >> >>> Begin forwarded message: >>> >>>> From: Tony Hosking >>>> Date: July 25, 2009 5:30:35 AM CDT >>>> To: hosking at cs.purdue.edu >>>> Subject: Output from "cron" command >>>> >>> >>>> Your "cron" job on niagara.cs.purdue.edu >>>> $HOME/cm3/scripts/regression/cron.sh >>>> >>>> produced the following output: >>>> >>>> U regression-scripts/defs.sh >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>> >>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.07.25 06:30:23 -- checkout in progress. >>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>> is set incorrectly, or the mail was delayed for a long time. >>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>> >>>> Error: Sending buildlog failed! >>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>> >>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.07.25 06:30:32 -- checkout in progress. >>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>> is set incorrectly, or the mail was delayed for a long time. >>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>> >>>> Error: Sending buildlog failed! >>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Jul 25 21:19:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:19:11 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: This line: echo tinderbox: timenow: `date +%s` needs to more like these lines: echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' 2009.07.25 12:13:54 -bash-3.00$ date '+%m.%d.%y %H:%M:%S' 07.25.09 12:14:33 -bash-3.00$ date +%s %s - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 20:44:38 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Quoting Tony Hosking : > >> Perhaps I am confusing with the original change I made for 1.10 to the >> parameter to the "date" command. >> >> In any case, something changed so that my scripts did not run >> properly. It's been a long time since I've seen a sane tinderbox run >> for Solaris -- will things be stabilising soon? > > I broke the last one yesterday with $() (fixed soon afterwards), but > the one before succeeded: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 > > I was hoping to get a green build from one of your systems today > (big-endian, different architecture) to finally fix the RC2 tag. > But if you cannot send your results to the tinderbox that will be > difficult :-/ I really don't understand why that should have stopped > working. > > The error below seems to be that the reported start time is 0, and > that cannot be according to the source. Could you set -x at the start > of the tinderbox script and try again? > > Jay, can you think of anything you have changed that may cause Tony's > problem? > > Olaf > >> -- Tony (not mobile) > :-) > >> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> This is an old error for Solaris that I fixed a long time ago. Can >>>> someone restore? >>> >>> Hi Tony, >>> >>> as far as I can see nothing has changed regarding STARTTIME: >>> >>> >>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>> >>> Annotations for scripts/regression/tinderbox-build.sh >>> *************** >>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>> '+%Y %m%d-%H%M%S'`" >>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>> 1.8 (wagner 03-Feb-08): echo " >>> date 'date +%s'" >>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>> %S'` -- checkout in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>> '+ %Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>> '+%Y. %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>> %H:%M: %S'` -- compile in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>> '+ %Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>> %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>> %H:%M: %S'` -- tests in progress." >>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>> '+%Y.%m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>> '+%Y. %m.%d %H:%M:%S'`]" >>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>> %S'` -- checkout, compile and test run done." >>> >>> Nothing at all has changed in these scripts in July: >>> >>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>> >>> Annotations for scripts/regression/tinderbox-build.sh >>> *************** >>> luthien [~/work/cm3] wagner >>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>> cm3.build cm3.build~ >>> luthien [~/work/cm3] wagner >>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>> >>> Annotations for scripts/regression/cm3.build >>> *************** >>> luthien [~/work/cm3] wagner >>> >>> >>> Perhaps I'm looking for the wrong thing. What exactly did you change >>> long ago to make it work? I'm at a loss now. >>> >>>> Sent from my iPhone >>> >>> You seem to be very `mobile' lately ;-) >>> >>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> U regression-scripts/defs.sh >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>> is set incorrectly, or the mail was delayed for a long time. >>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>> >>>>> Error: Sending buildlog failed! >>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>> is set incorrectly, or the mail was delayed for a long time. >>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>> >>>>> Error: Sending buildlog failed! >>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sat Jul 25 21:19:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:19:57 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: (two occurences of that) ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Fwd: Output from "cron" command > Date: Sat, 25 Jul 2009 19:19:11 +0000 > > > This line: > > > echo tinderbox: timenow: `date +%s` > > needs to more like these lines: > > echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." > > echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." > > > -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' > 2009.07.25 12:13:54 > > -bash-3.00$ date '+%m.%d.%y %H:%M:%S' > 07.25.09 12:14:33 > > -bash-3.00$ date +%s > %s > > - Jay > > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 20:44:38 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Quoting Tony Hosking : >> >>> Perhaps I am confusing with the original change I made for 1.10 to the >>> parameter to the "date" command. >>> >>> In any case, something changed so that my scripts did not run >>> properly. It's been a long time since I've seen a sane tinderbox run >>> for Solaris -- will things be stabilising soon? >> >> I broke the last one yesterday with $() (fixed soon afterwards), but >> the one before succeeded: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >> >> I was hoping to get a green build from one of your systems today >> (big-endian, different architecture) to finally fix the RC2 tag. >> But if you cannot send your results to the tinderbox that will be >> difficult :-/ I really don't understand why that should have stopped >> working. >> >> The error below seems to be that the reported start time is 0, and >> that cannot be according to the source. Could you set -x at the start >> of the tinderbox script and try again? >> >> Jay, can you think of anything you have changed that may cause Tony's >> problem? >> >> Olaf >> >>> -- Tony (not mobile) >> :-) >> >>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>> >>>> Quoting Tony Hosking : >>>> >>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>> someone restore? >>>> >>>> Hi Tony, >>>> >>>> as far as I can see nothing has changed regarding STARTTIME: >>>> >>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>>> >>>> Annotations for scripts/regression/tinderbox-build.sh >>>> *************** >>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>> '+%Y %m%d-%H%M%S'`" >>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>> 1.8 (wagner 03-Feb-08): echo " >>>> date 'date +%s'" >>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>> %S'` -- checkout in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>> '+%Y. %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>> %H:%M: %S'` -- compile in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>> %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>> %H:%M: %S'` -- tests in progress." >>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>> '+%Y.%m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>> '+%Y. %m.%d %H:%M:%S'`]" >>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>> %S'` -- checkout, compile and test run done." >>>> >>>> Nothing at all has changed in these scripts in July: >>>> >>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>> >>>> Annotations for scripts/regression/tinderbox-build.sh >>>> *************** >>>> luthien [~/work/cm3] wagner >>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>> cm3.build cm3.build~ >>>> luthien [~/work/cm3] wagner >>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>> >>>> Annotations for scripts/regression/cm3.build >>>> *************** >>>> luthien [~/work/cm3] wagner >>>> >>>> >>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>> long ago to make it work? I'm at a loss now. >>>> >>>>> Sent from my iPhone >>>> >>>> You seem to be very `mobile' lately ;-) >>>> >>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Tony Hosking >>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>> To: hosking at cs.purdue.edu >>>>>> Subject: Output from "cron" command >>>>>> >>>>> >>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>> >>>>>> produced the following output: >>>>>> >>>>>> U regression-scripts/defs.sh >>>>>> TESTHOSTNAME=niagara >>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>> LASTREL=5.4.0 >>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>> CM3_OSTYPE=POSIX >>>>>> CM3_TARGET=SOLgnu >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSUSER= >>>>>> testing ssh birch.elegosoft.com.. >>>>>> ssh birch.elegosoft.com ok >>>>>> Building cm3. >>>>>> Tinderbox Tree: "cm3" >>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>> >>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>> >>>>>> --- >>>>>> >>>>>> checkout, compile and test of cm3 ... >>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>> >>>>>> Error: Sending buildlog failed! >>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>> cleaning CM3 workspaces... >>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>> >>>>>> cleaning regression test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>> >>>>>> cleaning m3test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>> >>>>>> cleaning snapshot files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>> >>>>>> cleaning package reports... >>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>> >>>>>> TESTHOSTNAME=niagara >>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>> LASTREL=5.4.0 >>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>> CM3_OSTYPE=POSIX >>>>>> CM3_TARGET=SOLgnu >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>> CM3CVSUSER= >>>>>> testing ssh birch.elegosoft.com.. >>>>>> ssh birch.elegosoft.com ok >>>>>> Building cm3. >>>>>> Tinderbox Tree: "cm3" >>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>> >>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>> >>>>>> --- >>>>>> >>>>>> checkout, compile and test of cm3 ... >>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>> >>>>>> Error: Sending buildlog failed! >>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>> cleaning CM3 workspaces... >>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>> >>>>>> cleaning regression test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>> >>>>>> cleaning m3test log files... >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>> >>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>> >>>>>> cleaning snapshot files... >>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>> >>>>>> cleaning package reports... >>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sat Jul 25 21:26:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Jul 2009 19:26:37 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: Can I suggest the portable scripting language C? -bash-3.00$ cat date.c #include #include #include int main() { printf("%lu\n", (unsigned long)time(NULL)); return 0; } -bash-3.00$ cc date.c -o ./mydate -bash-3.00$ ./mydate 1248549753 -bash-3.00$ pwd /dev2/cm3/scripts use that instead? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > Date: Sat, 25 Jul 2009 19:19:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > > (two occurences of that) > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sat, 25 Jul 2009 19:19:11 +0000 >> >> >> This line: >> >> >> echo tinderbox: timenow: `date +%s` >> >> needs to more like these lines: >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." >> >> >> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >> 2009.07.25 12:13:54 >> >> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >> 07.25.09 12:14:33 >> >> -bash-3.00$ date +%s >> %s >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>> parameter to the "date" command. >>>> >>>> In any case, something changed so that my scripts did not run >>>> properly. It's been a long time since I've seen a sane tinderbox run >>>> for Solaris -- will things be stabilising soon? >>> >>> I broke the last one yesterday with $() (fixed soon afterwards), but >>> the one before succeeded: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>> >>> I was hoping to get a green build from one of your systems today >>> (big-endian, different architecture) to finally fix the RC2 tag. >>> But if you cannot send your results to the tinderbox that will be >>> difficult :-/ I really don't understand why that should have stopped >>> working. >>> >>> The error below seems to be that the reported start time is 0, and >>> that cannot be according to the source. Could you set -x at the start >>> of the tinderbox script and try again? >>> >>> Jay, can you think of anything you have changed that may cause Tony's >>> problem? >>> >>> Olaf >>> >>>> -- Tony (not mobile) >>> :-) >>> >>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>> someone restore? >>>>> >>>>> Hi Tony, >>>>> >>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>> >>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep 'STARTTIME| date' >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>> '+%Y %m%d-%H%M%S'`" >>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>> 1.8 (wagner 03-Feb-08): echo " >>>>> date 'date +%s'" >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- compile in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>> %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- tests in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout, compile and test run done." >>>>> >>>>> Nothing at all has changed in these scripts in July: >>>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>> cm3.build cm3.build~ >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/cm3.build >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> >>>>> >>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>> long ago to make it work? I'm at a loss now. >>>>> >>>>>> Sent from my iPhone >>>>> >>>>> You seem to be very `mobile' lately ;-) >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Tony Hosking >>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Subject: Output from "cron" command >>>>>>> >>>>>> >>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>> >>>>>>> produced the following output: >>>>>>> >>>>>>> U regression-scripts/defs.sh >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From wagner at elegosoft.com Sat Jul 25 21:52:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 21:52:13 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> I don't see how that will help us... It worked for Tony for over a year, and nothing obvious has changed. Or did something change on your side, Tony (system upgrade, path setting, ...)? It's not good to introduce arbitrary changes now without understanding why it breaks. Olaf Quoting Jay K : > > Can I suggest the portable scripting language C? > > > -bash-3.00$ cat date.c > #include > #include > #include > int main() > { > printf("%lu\n", (unsigned long)time(NULL)); > return 0; > } > -bash-3.00$ cc date.c -o ./mydate > -bash-3.00$ ./mydate > 1248549753 > -bash-3.00$ pwd > /dev2/cm3/scripts > > > use that instead? > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> Date: Sat, 25 Jul 2009 19:19:57 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> >> (two occurences of that) >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>> >>> >>> This line: >>> >>> >>> echo tinderbox: timenow: `date +%s` >>> >>> needs to more like these lines: >>> >>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>> >>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run done." >>> >>> >>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>> 2009.07.25 12:13:54 >>> >>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>> 07.25.09 12:14:33 >>> >>> -bash-3.00$ date +%s >>> %s >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>> From: wagner at elegosoft.com >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> Quoting Tony Hosking : >>>> >>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>> parameter to the "date" command. >>>>> >>>>> In any case, something changed so that my scripts did not run >>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>> for Solaris -- will things be stabilising soon? >>>> >>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>> the one before succeeded: >>>> >>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>> >>>> I was hoping to get a green build from one of your systems today >>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>> But if you cannot send your results to the tinderbox that will be >>>> difficult :-/ I really don't understand why that should have stopped >>>> working. >>>> >>>> The error below seems to be that the reported start time is 0, and >>>> that cannot be according to the source. Could you set -x at the start >>>> of the tinderbox script and try again? >>>> >>>> Jay, can you think of anything you have changed that may cause Tony's >>>> problem? >>>> >>>> Olaf >>>> >>>>> -- Tony (not mobile) >>>> :-) >>>> >>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>> >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>> someone restore? >>>>>> >>>>>> Hi Tony, >>>>>> >>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>> >>>>>> >>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>> 'STARTTIME| date' >>>>>> >>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>> *************** >>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>> '+%Y %m%d-%H%M%S'`" >>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>> date 'date +%s'" >>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>> %S'` -- checkout in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>> %H:%M: %S'` -- compile in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>> %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>> %H:%M: %S'` -- tests in progress." >>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>> %S'` -- checkout, compile and test run done." >>>>>> >>>>>> Nothing at all has changed in these scripts in July: >>>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>> >>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>> *************** >>>>>> luthien [~/work/cm3] wagner >>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>> cm3.build cm3.build~ >>>>>> luthien [~/work/cm3] wagner >>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>> >>>>>> Annotations for scripts/regression/cm3.build >>>>>> *************** >>>>>> luthien [~/work/cm3] wagner >>>>>> >>>>>> >>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>> long ago to make it work? I'm at a loss now. >>>>>> >>>>>>> Sent from my iPhone >>>>>> >>>>>> You seem to be very `mobile' lately ;-) >>>>>> >>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: Tony Hosking >>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Subject: Output from "cron" command >>>>>>>> >>>>>>> >>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>> >>>>>>>> produced the following output: >>>>>>>> >>>>>>>> U regression-scripts/defs.sh >>>>>>>> TESTHOSTNAME=niagara >>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>> LASTREL=5.4.0 >>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>> CM3_OSTYPE=POSIX >>>>>>>> CM3_TARGET=SOLgnu >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSUSER= >>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>> ssh birch.elegosoft.com ok >>>>>>>> Building cm3. >>>>>>>> Tinderbox Tree: "cm3" >>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>> >>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> checkout, compile and test of cm3 ... >>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>> >>>>>>>> Error: Sending buildlog failed! >>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>> cleaning CM3 workspaces... >>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>> >>>>>>>> cleaning regression test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>> >>>>>>>> cleaning m3test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>> >>>>>>>> cleaning snapshot files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>> >>>>>>>> cleaning package reports... >>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>> >>>>>>>> TESTHOSTNAME=niagara >>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>> LASTREL=5.4.0 >>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>> CM3_OSTYPE=POSIX >>>>>>>> CM3_TARGET=SOLgnu >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>> CM3CVSUSER= >>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>> ssh birch.elegosoft.com ok >>>>>>>> Building cm3. >>>>>>>> Tinderbox Tree: "cm3" >>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>> >>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> checkout, compile and test of cm3 ... >>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 minutes) >>>>>>>> >>>>>>>> Error: Sending buildlog failed! >>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>> cleaning CM3 workspaces... >>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>> >>>>>>>> cleaning regression test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>> >>>>>>>> cleaning m3test log files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>> >>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>> >>>>>>>> cleaning snapshot files... >>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>> >>>>>>>> cleaning package reports... >>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jul 25 21:54:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 15:54:49 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> Message-ID: Hmm. This is weird. I already have my own version of date (which accepts +%s) installed in my path so it should just work. My cron jobs sets the path accordingly: #/bin/sh CVS_RSH=ssh PATH=$HOME/bin:/opt/csw/bin:/opt/csw/gcc3/bin:/usr/ccs/bin:$PATH export CVS_RSH export PATH cd $HOME/cm3/scripts/regression ./tinderbox-build.sh cm3.build BUILD_REL=lastok ./tinderbox-build.sh cm3.build so I don't know where this new error is coming from (as Olaf points out tinderbox-build.sh hasn't changed significantly in any way that would trigger an error). Is there some other script not getting my private version $HOME/bin/date? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 25 Jul 2009, at 15:19, Jay K wrote: > > (two occurences of that) > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sat, 25 Jul 2009 19:19:11 +0000 >> >> >> This line: >> >> >> echo tinderbox: timenow: `date +%s` >> >> needs to more like these lines: >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >> >> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test run >> done." >> >> >> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >> 2009.07.25 12:13:54 >> >> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >> 07.25.09 12:14:33 >> >> -bash-3.00$ date +%s >> %s >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> Perhaps I am confusing with the original change I made for 1.10 >>>> to the >>>> parameter to the "date" command. >>>> >>>> In any case, something changed so that my scripts did not run >>>> properly. It's been a long time since I've seen a sane tinderbox >>>> run >>>> for Solaris -- will things be stabilising soon? >>> >>> I broke the last one yesterday with $() (fixed soon afterwards), but >>> the one before succeeded: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>> >>> I was hoping to get a green build from one of your systems today >>> (big-endian, different architecture) to finally fix the RC2 tag. >>> But if you cannot send your results to the tinderbox that will be >>> difficult :-/ I really don't understand why that should have stopped >>> working. >>> >>> The error below seems to be that the reported start time is 0, and >>> that cannot be according to the source. Could you set -x at the >>> start >>> of the tinderbox script and try again? >>> >>> Jay, can you think of anything you have changed that may cause >>> Tony's >>> problem? >>> >>> Olaf >>> >>>> -- Tony (not mobile) >>> :-) >>> >>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> This is an old error for Solaris that I fixed a long time ago. >>>>>> Can >>>>>> someone restore? >>>>> >>>>> Hi Tony, >>>>> >>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>> >>>>> >>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>> 'STARTTIME| date' >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>> '+%Y %m%d-%H%M%S'`" >>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>> 1.8 (wagner 03-Feb-08): echo " >>>>> date 'date +%s'" >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- compile in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>> %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>> %H:%M: %S'` -- tests in progress." >>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>> %S'` -- checkout, compile and test run done." >>>>> >>>>> Nothing at all has changed in these scripts in July: >>>>> >>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>> cm3.build cm3.build~ >>>>> luthien [~/work/cm3] wagner >>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>> >>>>> Annotations for scripts/regression/cm3.build >>>>> *************** >>>>> luthien [~/work/cm3] wagner >>>>> >>>>> >>>>> Perhaps I'm looking for the wrong thing. What exactly did you >>>>> change >>>>> long ago to make it work? I'm at a loss now. >>>>> >>>>>> Sent from my iPhone >>>>> >>>>> You seem to be very `mobile' lately ;-) >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Tony Hosking >>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Subject: Output from "cron" command >>>>>>> >>>>>> >>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>> >>>>>>> produced the following output: >>>>>>> >>>>>>> U regression-scripts/defs.sh >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>>>> TESTHOSTNAME=niagara >>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>> LASTREL=5.4.0 >>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>> CM3_OSTYPE=POSIX >>>>>>> CM3_TARGET=SOLgnu >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>> CM3CVSUSER= >>>>>>> testing ssh birch.elegosoft.com.. >>>>>>> ssh birch.elegosoft.com ok >>>>>>> Building cm3. >>>>>>> Tinderbox Tree: "cm3" >>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>> >>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/log.txt >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> checkout, compile and test of cm3 ... >>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>>>>>> minutes) >>>>>>> >>>>>>> Error: Sending buildlog failed! >>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>> cleaning CM3 workspaces... >>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>> >>>>>>> cleaning regression test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>> >>>>>>> cleaning m3test log files... >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>> >>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>> >>>>>>> cleaning snapshot files... >>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>> >>>>>>> cleaning package reports... >>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jul 25 21:55:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Jul 2009 15:55:07 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> Message-ID: I've not changed anything on my side. On 25 Jul 2009, at 15:52, Olaf Wagner wrote: > I don't see how that will help us... It worked for Tony for over > a year, and nothing obvious has changed. Or did something change on > your side, Tony (system upgrade, path setting, ...)? > > It's not good to introduce arbitrary changes now without understanding > why it breaks. > > Olaf > > Quoting Jay K : > >> >> Can I suggest the portable scripting language C? >> >> >> -bash-3.00$ cat date.c >> #include >> #include >> #include >> int main() >> { >> printf("%lu\n", (unsigned long)time(NULL)); >> return 0; >> } >> -bash-3.00$ cc date.c -o ./mydate >> -bash-3.00$ ./mydate >> 1248549753 >> -bash-3.00$ pwd >> /dev2/cm3/scripts >> >> >> use that instead? >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> >>> (two occurences of that) >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>> >>>> >>>> This line: >>>> >>>> >>>> echo tinderbox: timenow: `date +%s` >>>> >>>> needs to more like these lines: >>>> >>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>> >>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>> run done." >>>> >>>> >>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>> 2009.07.25 12:13:54 >>>> >>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>> 07.25.09 12:14:33 >>>> >>>> -bash-3.00$ date +%s >>>> %s >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>> >>>>> Quoting Tony Hosking : >>>>> >>>>>> Perhaps I am confusing with the original change I made for 1.10 >>>>>> to the >>>>>> parameter to the "date" command. >>>>>> >>>>>> In any case, something changed so that my scripts did not run >>>>>> properly. It's been a long time since I've seen a sane >>>>>> tinderbox run >>>>>> for Solaris -- will things be stabilising soon? >>>>> >>>>> I broke the last one yesterday with $() (fixed soon afterwards), >>>>> but >>>>> the one before succeeded: >>>>> >>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>> >>>>> I was hoping to get a green build from one of your systems today >>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>> But if you cannot send your results to the tinderbox that will be >>>>> difficult :-/ I really don't understand why that should have >>>>> stopped >>>>> working. >>>>> >>>>> The error below seems to be that the reported start time is 0, and >>>>> that cannot be according to the source. Could you set -x at the >>>>> start >>>>> of the tinderbox script and try again? >>>>> >>>>> Jay, can you think of anything you have changed that may cause >>>>> Tony's >>>>> problem? >>>>> >>>>> Olaf >>>>> >>>>>> -- Tony (not mobile) >>>>> :-) >>>>> >>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>> >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>> ago. Can >>>>>>>> someone restore? >>>>>>> >>>>>>> Hi Tony, >>>>>>> >>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>> >>>>>>> >>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>> 'STARTTIME| date' >>>>>>> >>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>> *************** >>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>> date 'date +%s'" >>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>> %S'` -- checkout in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>> %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>> %S'` -- checkout, compile and test run done." >>>>>>> >>>>>>> Nothing at all has changed in these scripts in July: >>>>>>> >>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>> >>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>> *************** >>>>>>> luthien [~/work/cm3] wagner >>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>> cm3.build cm3.build~ >>>>>>> luthien [~/work/cm3] wagner >>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>> >>>>>>> Annotations for scripts/regression/cm3.build >>>>>>> *************** >>>>>>> luthien [~/work/cm3] wagner >>>>>>> >>>>>>> >>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you >>>>>>> change >>>>>>> long ago to make it work? I'm at a loss now. >>>>>>> >>>>>>>> Sent from my iPhone >>>>>>> >>>>>>> You seem to be very `mobile' lately ;-) >>>>>>> >>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> From: Tony Hosking >>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Subject: Output from "cron" command >>>>>>>>> >>>>>>>> >>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>> >>>>>>>>> produced the following output: >>>>>>>>> >>>>>>>>> U regression-scripts/defs.sh >>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>> LASTREL=5.4.0 >>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSUSER= >>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>> Building cm3. >>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>> >>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>> log.txt >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>> minutes) >>>>>>>>> >>>>>>>>> Error: Sending buildlog failed! >>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>> cleaning CM3 workspaces... >>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>> >>>>>>>>> cleaning regression test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>> >>>>>>>>> cleaning m3test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>> >>>>>>>>> cleaning snapshot files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>> >>>>>>>>> cleaning package reports... >>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>> >>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>> LASTREL=5.4.0 >>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>> CM3CVSUSER= >>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>> Building cm3. >>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>> >>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>> log.txt >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>> variable timenow: 0, timenow: 1248517835, (-20808630.5833333 >>>>>>>>> minutes) >>>>>>>>> >>>>>>>>> Error: Sending buildlog failed! >>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>> cleaning CM3 workspaces... >>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>> >>>>>>>>> cleaning regression test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>> >>>>>>>>> cleaning m3test log files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>> >>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>> >>>>>>>>> cleaning snapshot files... >>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>> >>>>>>>>> cleaning package reports... >>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>> >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>> Sitz: Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>> 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>> IdNr: DE163214194 >>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jul 25 22:00:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 25 Jul 2009 22:00:15 +0200 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> Message-ID: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Quoting Tony Hosking : > I've not changed anything on my side. I don't understand why I missed that: revision 1.13 date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; let's just try plain date, based on the choices in the error message ---------------------------- But you seem to have fixed it already: revision 1.14 date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: yRpWy2mygKpT88Xt; Revert to what used to work. Strange that it didn't show up in my first diff. Olaf > > On 25 Jul 2009, at 15:52, Olaf Wagner wrote: > >> I don't see how that will help us... It worked for Tony for over >> a year, and nothing obvious has changed. Or did something change on >> your side, Tony (system upgrade, path setting, ...)? >> >> It's not good to introduce arbitrary changes now without understanding >> why it breaks. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Can I suggest the portable scripting language C? >>> >>> >>> -bash-3.00$ cat date.c >>> #include >>> #include >>> #include >>> int main() >>> { >>> printf("%lu\n", (unsigned long)time(NULL)); >>> return 0; >>> } >>> -bash-3.00$ cc date.c -o ./mydate >>> -bash-3.00$ ./mydate >>> 1248549753 >>> -bash-3.00$ pwd >>> /dev2/cm3/scripts >>> >>> >>> use that instead? >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> >>>> (two occurences of that) >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>> >>>>> >>>>> This line: >>>>> >>>>> >>>>> echo tinderbox: timenow: `date +%s` >>>>> >>>>> needs to more like these lines: >>>>> >>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>> >>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>> run done." >>>>> >>>>> >>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>> 2009.07.25 12:13:54 >>>>> >>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>> 07.25.09 12:14:33 >>>>> >>>>> -bash-3.00$ date +%s >>>>> %s >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>> >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>> parameter to the "date" command. >>>>>>> >>>>>>> In any case, something changed so that my scripts did not run >>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>> for Solaris -- will things be stabilising soon? >>>>>> >>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>> the one before succeeded: >>>>>> >>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>> >>>>>> I was hoping to get a green build from one of your systems today >>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>> But if you cannot send your results to the tinderbox that will be >>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>> working. >>>>>> >>>>>> The error below seems to be that the reported start time is 0, and >>>>>> that cannot be according to the source. Could you set -x at the start >>>>>> of the tinderbox script and try again? >>>>>> >>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>> problem? >>>>>> >>>>>> Olaf >>>>>> >>>>>>> -- Tony (not mobile) >>>>>> :-) >>>>>> >>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>> >>>>>>>> Quoting Tony Hosking : >>>>>>>> >>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>> someone restore? >>>>>>>> >>>>>>>> Hi Tony, >>>>>>>> >>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>> >>>>>>>> >>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>> 'STARTTIME| date' >>>>>>>> >>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>> *************** >>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>> date 'date +%s'" >>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>> %S'` -- checkout in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>> >>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>> >>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>> >>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>> *************** >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>> cm3.build cm3.build~ >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>> >>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>> *************** >>>>>>>> luthien [~/work/cm3] wagner >>>>>>>> >>>>>>>> >>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>> >>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>>> From: Tony Hosking >>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>> >>>>>>>>>> produced the following output: >>>>>>>>>> >>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSUSER= >>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>> Building cm3. >>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>> >>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>> >>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>> >>>>>>>>>> cleaning regression test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>> >>>>>>>>>> cleaning m3test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>> >>>>>>>>>> cleaning snapshot files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>> >>>>>>>>>> cleaning package reports... >>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>> >>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>> CM3CVSUSER= >>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>> Building cm3. >>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>> >>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>> >>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>> >>>>>>>>>> cleaning regression test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>> >>>>>>>>>> cleaning m3test log files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>> >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>> >>>>>>>>>> cleaning snapshot files... >>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>> >>>>>>>>>> cleaning package reports... >>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>> >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>> 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>> Sitz: Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>> DE163214194 >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>> 23 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>> IdNr: DE163214194 >>>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 05:09:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 03:09:59 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: Tony reverted it. I'm bringing my Solaris/sparc machine up to date and will try running Tinderbox. I will likely try with plain date and see what happens there and otherwise. - Jay ---------------------------------------- > Date: Sat, 25 Jul 2009 22:00:15 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Quoting Tony Hosking : > >> I've not changed anything on my side. > > I don't understand why I missed that: > > revision 1.13 > date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; > let's just try plain date, based on the choices in the error message > ---------------------------- > > But you seem to have fixed it already: > > revision 1.14 > date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: yRpWy2mygKpT88Xt; > Revert to what used to work. > > Strange that it didn't show up in my first diff. > > Olaf > > >> >> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >> >>> I don't see how that will help us... It worked for Tony for over >>> a year, and nothing obvious has changed. Or did something change on >>> your side, Tony (system upgrade, path setting, ...)? >>> >>> It's not good to introduce arbitrary changes now without understanding >>> why it breaks. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Can I suggest the portable scripting language C? >>>> >>>> >>>> -bash-3.00$ cat date.c >>>> #include >>>> #include >>>> #include >>>> int main() >>>> { >>>> printf("%lu\n", (unsigned long)time(NULL)); >>>> return 0; >>>> } >>>> -bash-3.00$ cc date.c -o ./mydate >>>> -bash-3.00$ ./mydate >>>> 1248549753 >>>> -bash-3.00$ pwd >>>> /dev2/cm3/scripts >>>> >>>> >>>> use that instead? >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>> >>>>> >>>>> (two occurences of that) >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>> >>>>>> >>>>>> This line: >>>>>> >>>>>> >>>>>> echo tinderbox: timenow: `date +%s` >>>>>> >>>>>> needs to more like these lines: >>>>>> >>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>> >>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>> run done." >>>>>> >>>>>> >>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>> 2009.07.25 12:13:54 >>>>>> >>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>> 07.25.09 12:14:33 >>>>>> >>>>>> -bash-3.00$ date +%s >>>>>> %s >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>> From: wagner at elegosoft.com >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>> >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>>> parameter to the "date" command. >>>>>>>> >>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>> >>>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>>> the one before succeeded: >>>>>>> >>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>> >>>>>>> I was hoping to get a green build from one of your systems today >>>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>>> But if you cannot send your results to the tinderbox that will be >>>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>>> working. >>>>>>> >>>>>>> The error below seems to be that the reported start time is 0, and >>>>>>> that cannot be according to the source. Could you set -x at the start >>>>>>> of the tinderbox script and try again? >>>>>>> >>>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>>> problem? >>>>>>> >>>>>>> Olaf >>>>>>> >>>>>>>> -- Tony (not mobile) >>>>>>> :-) >>>>>>> >>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Quoting Tony Hosking : >>>>>>>>> >>>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>>> someone restore? >>>>>>>>> >>>>>>>>> Hi Tony, >>>>>>>>> >>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>> >>>>>>>>> >>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>> 'STARTTIME| date' >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>> *************** >>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>> date 'date +%s'" >>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>> %S'` -- checkout in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>> >>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>> >>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>> *************** >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>> cm3.build cm3.build~ >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>> >>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>> *************** >>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>> >>>>>>>>> >>>>>>>>>> Begin forwarded message: >>>>>>>>>> >>>>>>>>>>> From: Tony Hosking >>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>> >>>>>>>>>>> produced the following output: >>>>>>>>>>> >>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>> Building cm3. >>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>> >>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>>> >>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>> >>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>> >>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>> >>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>> >>>>>>>>>>> cleaning package reports... >>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>> >>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>> Building cm3. >>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>> >>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>> >>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>> >>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>> >>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>> >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>> >>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>> >>>>>>>>>>> cleaning package reports... >>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>> Sitz: Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>> DE163214194 >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>> IdNr: DE163214194 >>>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 26 06:23:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 04:23:40 +0000 Subject: [M3devel] "32" in target names? Message-ID: "32" in target names? I introduced: PPC32_OPENBSD PA32_HPUX SPARC32_LINUX Should these be renamed? PPC_OPENBSD SPARC_LINUX PA_HPUX? HPPA_HPUX? In the case of the last two, 64bit targets are a pretty clear possibility -- SPARC64_LINUX, PA64_HPUX?HPPA64_HPUX Less so for PPC64 -- Linux, Darwin, AIX, sure, but PPC64_*BSD doesn't seem to be happening. - Jay From jay.krell at cornell.edu Sun Jul 26 09:25:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 07:25:04 +0000 Subject: [M3devel] Tinderbox/Hudson Message-ID: - The links to my Tinderbox test results don't work. - Why are my Tinderbox status usually yellow even though the logs look ok? Due the missing test results? - I do already have Hudson server running OpenBSD/x86, that was easy, not configured yet (still cross building cm3 and will try a Tinderbox run first instead.) LINUXLIBC6 is yellow, but this looks ok: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 Do they have to be more recent? Or need last release and last ok? I only do last ok. You don't have last release for AMD64_LINUX, it doesn't exist, but are green. Maybe two separate builds are needed? SPARC32_LINUX is yellow but it also looks ok. http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 The most recent completed PPC_LINUX failed to get much of the source tree in the CVS checkout. That happens often. I should probably put in a retry or something.. (Bringing back I386_DARWIN, funny thing there, is that to compile X client, you need Python, and the in-box one isn't new enough, and current doesn't build out of the box because it assumes a full Mac system..still working on it..) - Jay From wagner at elegosoft.com Sun Jul 26 11:10:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 11:10:41 +0200 Subject: [M3devel] "32" in target names? In-Reply-To: References: Message-ID: <20090726111041.dx7sjj2hw44g0gck@mail.elegosoft.com> Quoting Jay K : > "32" in target names? > > I introduced: > PPC32_OPENBSD > PA32_HPUX > SPARC32_LINUX > > > Should these be renamed? > PPC_OPENBSD > SPARC_LINUX > PA_HPUX? HPPA_HPUX? > In the case of the last two, 64bit targets are a pretty clear > possibility -- SPARC64_LINUX, PA64_HPUX?HPPA64_HPUX > Less so for PPC64 -- Linux, Darwin, AIX, sure, but PPC64_*BSD > doesn't seem to be happening. I vote for keeping a clear distinction, so keep the 32. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Jul 26 11:17:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 11:17:49 +0200 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: References: Message-ID: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Quoting Jay K : > - The links to my Tinderbox test results don't work. > > - Why are my Tinderbox status usually yellow even though the logs look ok? > Due the missing test results? > > - I do already have Hudson server running OpenBSD/x86, that was > easy, not configured yet (still cross building cm3 and will try a > Tinderbox run first instead.) > > LINUXLIBC6 is yellow, but this looks ok: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 > > Do they have to be more recent? Or need last release and last ok? > I only do last ok. You don't have last release for AMD64_LINUX, it > doesn't exist, but are green. > Maybe two separate builds are needed? > > SPARC32_LINUX is yellow but it also looks ok. > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 Tinderbox shows running builds that haven't complete yet in yellow. Results are either green, red, or orange. So the result transfer to the server may have failed. > The most recent completed PPC_LINUX failed to get much of the source > tree in the CVS checkout. That happens often. I should probably put > in a retry or something.. No. You should probably do something about your network connection ;-) BTW, the exit you put in after the cvs checkout won't work this way. Unless you use special bash pipe result evaluation, it's always the _last_ process in a pipe that determines its result code. > (Bringing back I386_DARWIN, funny thing there, is that to compile X > client, you need Python, and the in-box one isn't new enough, and > current doesn't build out of the box because it assumes a full Mac > system..still working on it..) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 11:19:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 09:19:42 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: Looking at your Hudson jobs..to create my own.. I notice you run test_m3tests manually. I'll try that. Maybe of the yellow jobs ran to completion..but maybe because I didn't run test_m3tests? - Jay ---------------------------------------- > Date: Sun, 26 Jul 2009 11:17:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Tinderbox/Hudson > > Quoting Jay K : > >> - The links to my Tinderbox test results don't work. >> >> - Why are my Tinderbox status usually yellow even though the logs look ok? >> Due the missing test results? >> >> - I do already have Hudson server running OpenBSD/x86, that was >> easy, not configured yet (still cross building cm3 and will try a >> Tinderbox run first instead.) >> >> LINUXLIBC6 is yellow, but this looks ok: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >> >> Do they have to be more recent? Or need last release and last ok? >> I only do last ok. You don't have last release for AMD64_LINUX, it >> doesn't exist, but are green. >> Maybe two separate builds are needed? >> >> SPARC32_LINUX is yellow but it also looks ok. >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 > > Tinderbox shows running builds that haven't complete yet in yellow. > Results are either green, red, or orange. So the result transfer to > the server may have failed. > >> The most recent completed PPC_LINUX failed to get much of the source >> tree in the CVS checkout. That happens often. I should probably put >> in a retry or something.. > > No. You should probably do something about your network connection ;-) > > BTW, the exit you put in after the cvs checkout won't work this way. > Unless you use special bash pipe result evaluation, it's always the > _last_ process in a pipe that determines its result code. > >> (Bringing back I386_DARWIN, funny thing there, is that to compile X >> client, you need Python, and the in-box one isn't new enough, and >> current doesn't build out of the box because it assumes a full Mac >> system..still working on it..) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 26 12:07:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 10:07:51 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: I'm running Tinderbox on SOLgnu now. It fails with that error without a change and gets past the first email if I change the date commands. The first cvs checkout eventually failed, trying again.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Fwd: Output from "cron" command > Date: Sun, 26 Jul 2009 03:09:59 +0000 > > > Tony reverted it. I'm bringing my Solaris/sparc machine up to date and will try running Tinderbox. > I will likely try with plain date and see what happens there and otherwise. > > - Jay > > > > ---------------------------------------- >> Date: Sat, 25 Jul 2009 22:00:15 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Quoting Tony Hosking : >> >>> I've not changed anything on my side. >> >> I don't understand why I missed that: >> >> revision 1.13 >> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >> let's just try plain date, based on the choices in the error message >> ---------------------------- >> >> But you seem to have fixed it already: >> >> revision 1.14 >> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >> Revert to what used to work. >> >> Strange that it didn't show up in my first diff. >> >> Olaf >> >> >>> >>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>> >>>> I don't see how that will help us... It worked for Tony for over >>>> a year, and nothing obvious has changed. Or did something change on >>>> your side, Tony (system upgrade, path setting, ...)? >>>> >>>> It's not good to introduce arbitrary changes now without understanding >>>> why it breaks. >>>> >>>> Olaf >>>> >>>> Quoting Jay K : >>>> >>>>> >>>>> Can I suggest the portable scripting language C? >>>>> >>>>> >>>>> -bash-3.00$ cat date.c >>>>> #include >>>>> #include >>>>> #include >>>>> int main() >>>>> { >>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>> return 0; >>>>> } >>>>> -bash-3.00$ cc date.c -o ./mydate >>>>> -bash-3.00$ ./mydate >>>>> 1248549753 >>>>> -bash-3.00$ pwd >>>>> /dev2/cm3/scripts >>>>> >>>>> >>>>> use that instead? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>> >>>>>> >>>>>> (two occurences of that) >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>> >>>>>>> >>>>>>> This line: >>>>>>> >>>>>>> >>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>> >>>>>>> needs to more like these lines: >>>>>>> >>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>> >>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>> run done." >>>>>>> >>>>>>> >>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>> 2009.07.25 12:13:54 >>>>>>> >>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>> 07.25.09 12:14:33 >>>>>>> >>>>>>> -bash-3.00$ date +%s >>>>>>> %s >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>> From: wagner at elegosoft.com >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>> >>>>>>>> Quoting Tony Hosking : >>>>>>>> >>>>>>>>> Perhaps I am confusing with the original change I made for 1.10 to the >>>>>>>>> parameter to the "date" command. >>>>>>>>> >>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>> properly. It's been a long time since I've seen a sane tinderbox run >>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>> >>>>>>>> I broke the last one yesterday with $() (fixed soon afterwards), but >>>>>>>> the one before succeeded: >>>>>>>> >>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>> >>>>>>>> I was hoping to get a green build from one of your systems today >>>>>>>> (big-endian, different architecture) to finally fix the RC2 tag. >>>>>>>> But if you cannot send your results to the tinderbox that will be >>>>>>>> difficult :-/ I really don't understand why that should have stopped >>>>>>>> working. >>>>>>>> >>>>>>>> The error below seems to be that the reported start time is 0, and >>>>>>>> that cannot be according to the source. Could you set -x at the start >>>>>>>> of the tinderbox script and try again? >>>>>>>> >>>>>>>> Jay, can you think of anything you have changed that may cause Tony's >>>>>>>> problem? >>>>>>>> >>>>>>>> Olaf >>>>>>>> >>>>>>>>> -- Tony (not mobile) >>>>>>>> :-) >>>>>>>> >>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>> >>>>>>>>>>> This is an old error for Solaris that I fixed a long time ago. Can >>>>>>>>>>> someone restore? >>>>>>>>>> >>>>>>>>>> Hi Tony, >>>>>>>>>> >>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>> *************** >>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>> date 'date +%s'" >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: $STARTTIME >>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>> >>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>> >>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep Jul-09 >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>> *************** >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>> >>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>> *************** >>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did you change >>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Begin forwarded message: >>>>>>>>>>> >>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>> >>>>>>>>>>>> produced the following output: >>>>>>>>>>>> >>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>> Building cm3. >>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>> >>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ log.txt >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 minutes) >>>>>>>>>>>> >>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023-tVaq2V ... >>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>> >>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>>> >>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>> >>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>> Building cm3. >>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>> >>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ log.txt >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: timenow:', is >>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your clock >>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long time. >>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>> >>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032-xba4dW ... >>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>> >>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>> >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>> >>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>>>>>>>>> >>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>> 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>> Sitz: Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>>> DE163214194 >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>> 23 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>> IdNr: DE163214194 >>>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sun Jul 26 12:49:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 12:49:49 +0200 Subject: [M3devel] CM3 release engineering status Message-ID: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> Here's the current status: * release branch created for 5.8 * Hudson continuous integration and Tinderbox default checkout changed to the release branch by default (instances out of my control) * end of code freeze on main trunk (seems it never crossed the 0 degree Celsius boundary anyway :-) * commit restriction for the release branch: - contact me for including changes there - needed: CVS start and end tag exactly identifying the change set to be included * reviewed all package test failures and fixed them (for FreeBSD4 and AMD64_LINUX) * only known good target platforms currently are FreeBSD4 and AMD64_LINUX * need status for at least LINUXLIBC6, NT386, SOLgnu additionally * will try to setup more regression testing under my control during the next week(s) * RC2 postponed until end of next week... hopefully we'll know more then see also https://projects.elego.de/cm3/roadmap and http://hudson.modula3.com:8080/view/cm3/ Thanks for your attention and cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 26 13:04:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 11:04:06 +0000 Subject: [M3devel] new errors wrt bc and [ Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248604850.21111 1) m3gdb/src/m3makefile gnu platform missing, I fixed it 2a) "/home/jay/work/cm3-ws/sparc3-2009-07-26-03-59-12/cm3/m3-sys/m3tests/src/m3makefile", line 279: quake runtime error: execution failed: execution of `bc? failed: errno=2 2b) /home/jay/work/cm3-ws/sparc3-2009-07-26-03-59-12/cm3/scripts/pkgmap.sh: line 360: bc: command not found 3) regression-scripts/defs.sh: line 776: [: too many arguments if [ "${TESTHOSTNAME}" = "birch.elegosoft.com" -a `who -m | cut -d ' ' -f1` = "m3" ]; then Maybe put an "x" in there? if [ "x${TESTHOSTNAME}" = "xbirch.elegosoft.com" -a `who -m | cut -d ' ' -f1` = "m3" ]; then ? (+2 for using Python..) - Jay From jay.krell at cornell.edu Sun Jul 26 14:48:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 12:48:20 +0000 Subject: [M3devel] the formsedit crash Message-ID: Ok here is the formsedit crash. This is on SOLgnu. I have also seen it on either PPC_DARWIN or PPC_LINUX. I can try those again. It doesn't happen every time, but some large fraction, like maybe half. I changed the SIGsEGV to an assertion failure. -bash-3.00$ export DISPLAY=192.168.1.120:0.0 -bash-3.00$ ./formsedit *** *** runtime error: *** failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 *** Abort (core dumped) You can't debug it live because you keep getting interrupted by sig usr2. -bash-3.00$ dbx formsedit core t at 1 (l at 1) terminated by signal KILL (Killed) 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! 0xfe3c00a4 These statements from the debugger about main/AddUnit don't make sense to me. Current function is main 13 RTLinker__AddUnit (FormsEdit_M3); (dbx) where current thread: t at 1 [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xfe4680b8 [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xfe467ca0 [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xfefa5adc Does the code really recurse like this? [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, 0xffbf9ca0, 0xfe4a5d 00, 0xfef48180), at 0xfef48520 [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, 0xff000000, 0x0, 0x0 ), at 0xff046ea4 [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, 0xffbf9e48, 0x0, 0xfefbcf58), at 0xfefbcf84 [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, 0xffbf9f18, 0 x0, 0xff0437d8), at 0xff043864 [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, 0x0, 0x0), at 0xff046ea4 [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, 0xffbfa0a8, 0x0, 0xfefbcf58), at 0xfefbcf84 [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, 0x0, 0x0), at 0xff046ea4 [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, 0xffbfa238, 0x0, 0xfefbcf58), at 0xfefbcf84 [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, 0x0, 0x0), at 0xff046ea4 [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, 0xffbfa3c8, 0x0, 0xfefbcf58), at 0xfefbcf84 [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, 0x0, 0x0), at 0xff046ea4 [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, 0xffbfa558, 0x0, 0xfefbcf58), at 0xfefbcf84 [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, 0x0, 0x0), at 0xff046ea4 [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, 0xffbfa6e8, 0x0, 0xfefbcf58), at 0xfefbcf84 [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, 0x0, 0x0), at 0xff046ea4 [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, 0xffbfa878, 0x0, 0xfefbcf58), at 0xfefbcf84 [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, 0x0, 0x0), at 0xff046ea4 [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, 0xffbfaa08, 0x0, 0xfefbcf58), at 0xfefbcf84 [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, 0x0, 0x0), at 0xff046ea4 [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, 0xffbfab98, 0x0, 0xfefbcf58), at 0xfefbcf84 [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, 0x0, 0x0), at 0xff046ea4 [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, 0xffbfad28, 0x0, 0xfefbcf58), at 0xfefbcf84 [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, 0x0, 0x0), at 0xff046ea4 [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, 0xffbfaeb8, 0x0, 0xfefbcf58), at 0xfefbcf84 [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, 0x0, 0x0), at 0xff046ea4 [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, 0xffbfb048, 0x0, 0xfefbcf58), at 0xfefbcf84 [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, 0x0, 0x0), at 0xff046ea4 [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, 0xffbfb1d8, 0x0, 0xfefbcf58), at 0xfefbcf84 [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, 0x0, 0x0), at 0xff046ea4 [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, 0xffbfb368, 0x0, 0xfefbcf58), at 0xfefbcf84 [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, 0x0, 0x0), at 0xff046ea4 [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, 0xffbfb4f8, 0x0, 0xfefbcf58), at 0xfefbcf84 [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, 0x0, 0x0), at 0xff046ea4 [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, 0xffbfb688, 0x0, 0xfefbcf58), at 0xfefbcf84 [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, 0x0, 0x0), at 0xff046ea4 [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, 0xffbfb818, 0x0, 0xfefbcf58), at 0xfefbcf84 [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, 0x0, 0x0), at 0xff046ea4 [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, 0xffbfb9a8, 0x0, 0xfefbcf58), at 0xfefbcf84 [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, 0x0, 0x0), at 0xff046ea4 [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, 0xffbfbb38, 0x0, 0xfefbcf58), at 0xfefbcf84 [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, 0x0, 0x0), at 0xff046ea4 [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, 0xffbfbcc8, 0x0, 0xfefbcf58), at 0xfefbcf84 [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, 0x0, 0x0), at 0xff046ea4 [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, 0xffbfbe58, 0x0, 0xfefbcf58), at 0xfefbcf84 [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, 0x0, 0x0), at 0xff046ea4 [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, 0xffbfbfe8, 0x0, 0xfefbcf58), at 0xfefbcf84 [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, 0x0, 0x0), at 0xff046ea4 [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, 0xffbfc178, 0x0, 0xfefbcf58), at 0xfefbcf84 [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, 0x0, 0x0), at 0xff046ea4 [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, 0xffbfc308, 0x0, 0xfefbcf58), at 0xfefbcf84 [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, 0x0, 0x0), at 0xff046ea4 [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, 0xffbfc498, 0x0, 0xfefbcf58), at 0xfefbcf84 [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, 0xfe1b2000, 0x6b170 , 0x0), at 0xff046ea4 [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, 0xff000000, 0x0, 0x0), at 0xff191d20 [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b27 0, 0x0), at 0xfefb6a38 [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d00, 0x0), at 0xfefbc9f4 [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, 0xfe1b2000, 0x6b290, 0x0), at 0xfefbc9f4 [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b2b 0, 0x0), at 0xfefb6a38 [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d00, 0x0), at 0xfefbc9f4 [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, 0xfe1b2000, 0x6b2d0, 0x0), at 0xfefbc9f4 [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6af7 0, 0x0), at 0xfefb6a38 [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, 0xff000000, 0x0, 0x0), at 0xfefbc9f4 [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b33 0, 0x0), at 0xfefb6a38 [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, 0xfe1b2000, 0x6b698, 0x0), at 0xfefbc9f4 [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, 0xfe1b2000, 0x6b69 8, 0x0), at 0xfefbc9f4 [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, 0xfe1b2000, 0xf e4a5d00, 0x0), at 0xfefeb348 [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, 0xfe1b2000, 0x6b6b8, 0x0), at 0xfefbc9f4 [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, 0xff000000, 0x0, 0x 0), at 0xff157730 [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b7f 8, 0x0), at 0xfefb6a38 [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, 0xfe1b2000, 0x6b858, 0x0), at 0xfefbc9f4 [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, 0x0, 0x0), at 0xfefb6a38 [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, 0xfe1b2000, 0x6b858, 0x0), at 0xfefbc9f4 [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, 0xff000000, 0x0 , 0x0), at 0xff18d2ec [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b87 8, 0x0), at 0xfefb6a38 [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, 0xfe1b2000, 0x6b898, 0x0), at 0xfefbc9f4 [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, 0xfe1b2000, 0x6b89 8, 0x0), at 0xfefbc9f4 [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, 0xfe1b2000, 0x6 b8b8, 0x0), at 0xfefeb348 [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, 0x20, 0xffbfd b20), at 0xfefb6a38 [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, 0xfe1b2000, 0x6b8b8, 0x0), at 0xfefbc9f4 [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xff01f884 [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, 0xfe1b2000, 0x6b8d8, 0x0), at 0xfefbc9f4 [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4 a5d00, 0x0), at 0xff19e338 [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, 0xfe1b2000, 0x60338, 0x0), at 0xfefbc9f4 [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, 0xfe1b2000, 0xfe4a5d 00, 0x0), at 0xfeff6db4 [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, 0xff000000, 0x0, 0 x0), at 0xfefb6a38 [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, 0xfe1b2000 , 0x6e5a0, 0x0), at 0xfefbc9f4 (dbx) (dbx) threads > t at 1 a l at 1 ?() LWP suspended in __lwp_park() t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in ___nanosleep () t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 in __lwp_pa rk() t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in ___nanosleep () t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 in __lwp_pa rk() t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 in __lwp_pa rk() t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 in __lwp_pa rk() o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in __lwp_kill( ) t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 in __lwp_pa rk() (dbx) The crashing thread: (dbx) thread t at 27 t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe3c11f4 (dbx) where current thread: t at 27 =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at 0xfe35fdd8 [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at 0xfe33fff8 [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at 0xfe46255c [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at 0xfe4529c8 [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, 0xfddf0900), at 0x fe44f2e4 [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, 0xfe4b4d90, 0xff2 50434), at 0xfe44ee5c [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, 0x100000), at 0xfe44fa0c [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678), at 0xfe44f590 [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc53131), at 0xfe44f44c [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, 0x0), at 0xfe46 470c [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678), at 0xfe44f680 [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc53661), at 0xfe44f44c [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xfdc538 e1), at 0xfe46470c [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, 0xfdc53a40, 0xfdc539 2c, 0xfdc53928), at 0xfe42ffe0 [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, 0xfdc53a40), a t 0xff141d64 (too many frames for an assertion failure imho!) [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, 0x1000, 0x0, 0x0), at 0xff13dda4 [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, 0xff000000, 0x0, 0x0), at 0xff13d9e8 [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, 0xfddf0800, 0x69da0, 0x0), at 0xff140730 [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0xff000000, 0xff00000 0, 0x0, 0x1), at 0xff1407d0 [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, 0xfdd221bc), a t 0xfefb8f04 [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at 0xfefc5170 [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, 0xfddf0800, 0x90 410, 0x0), at 0xfefc45a8 [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfefc4674 [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at 0xfe46bc00 [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, 0xfe46b740, 0x1) , at 0xfe46b790 (dbx) - Jay From jay.krell at cornell.edu Sun Jul 26 16:10:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 14:10:50 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: I don't think that is it but I don't know. I don't know the various paths through the scripts, haven't studied them enough.. for some reason my one run on SOLgnu did run the tests and turned green. Most of my runs stop after successful compile so stay yellow. I edited out that one line you said to. Maybe I should an -x run. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Tinderbox/Hudson > Date: Sun, 26 Jul 2009 09:19:42 +0000 > > > Looking at your Hudson jobs..to create my own.. I notice you run test_m3tests manually. I'll try that. > Maybe of the yellow jobs ran to completion..but maybe because I didn't run test_m3tests? > > - Jay > > > > ---------------------------------------- >> Date: Sun, 26 Jul 2009 11:17:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Tinderbox/Hudson >> >> Quoting Jay K : >> >>> - The links to my Tinderbox test results don't work. >>> >>> - Why are my Tinderbox status usually yellow even though the logs look ok? >>> Due the missing test results? >>> >>> - I do already have Hudson server running OpenBSD/x86, that was >>> easy, not configured yet (still cross building cm3 and will try a >>> Tinderbox run first instead.) >>> >>> LINUXLIBC6 is yellow, but this looks ok: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >>> >>> Do they have to be more recent? Or need last release and last ok? >>> I only do last ok. You don't have last release for AMD64_LINUX, it >>> doesn't exist, but are green. >>> Maybe two separate builds are needed? >>> >>> SPARC32_LINUX is yellow but it also looks ok. >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 >> >> Tinderbox shows running builds that haven't complete yet in yellow. >> Results are either green, red, or orange. So the result transfer to >> the server may have failed. >> >>> The most recent completed PPC_LINUX failed to get much of the source >>> tree in the CVS checkout. That happens often. I should probably put >>> in a retry or something.. >> >> No. You should probably do something about your network connection ;-) >> >> BTW, the exit you put in after the cvs checkout won't work this way. >> Unless you use special bash pipe result evaluation, it's always the >> _last_ process in a pipe that determines its result code. >> >>> (Bringing back I386_DARWIN, funny thing there, is that to compile X >>> client, you need Python, and the in-box one isn't new enough, and >>> current doesn't build out of the box because it assumes a full Mac >>> system..still working on it..) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Sun Jul 26 19:16:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 17:16:49 +0000 Subject: [M3devel] libz in Tinderbox? Message-ID: Tony can you install libz? Or should we import it? Or should we maybe probe for $HOME/lib/libz.a or somewhere else? http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake runtime error: file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib 22072 There is also: Must be attached to terminal for ?am I? option 49575 + [ niagara = birch.elegosoft.com -a = m3 ] 49576 ./tinderbox-build.sh: test: argument expected 49577 r4=1 49578 + expr 0 + 0 + 255 + 255 + 1 49579 + return 511 49580 + date +%Y.%m.%d %H:%M:%S 49581 + echo [end run-tests 2009.07.26 10:39:00] 49582 [end run-tests 2009.07.26 10:39:00] 49583 *** TESTS FAILED - Jay From hosking at cs.purdue.edu Sun Jul 26 19:44:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:44:39 -0400 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> Message-ID: <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> It did not used to be required that to build X clients on I386_DARWIN you needed Python. What changed? Sent from my iPhone On Jul 26, 2009, at 5:17 AM, Olaf Wagner wrote: > Quoting Jay K : > >> - The links to my Tinderbox test results don't work. >> >> - Why are my Tinderbox status usually yellow even though the logs >> look ok? >> Due the missing test results? >> >> - I do already have Hudson server running OpenBSD/x86, that was >> easy, not configured yet (still cross building cm3 and will try a >> Tinderbox run first instead.) >> >> LINUXLIBC6 is yellow, but this looks ok: >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >> >> Do they have to be more recent? Or need last release and last ok? >> I only do last ok. You don't have last release for AMD64_LINUX, it >> doesn't exist, but are green. >> Maybe two separate builds are needed? >> >> SPARC32_LINUX is yellow but it also looks ok. >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 > > Tinderbox shows running builds that haven't complete yet in yellow. > Results are either green, red, or orange. So the result transfer to > the server may have failed. > >> The most recent completed PPC_LINUX failed to get much of the >> source tree in the CVS checkout. That happens often. I should >> probably put in a retry or something.. > > No. You should probably do something about your network connection ;-) > > BTW, the exit you put in after the cvs checkout won't work this way. > Unless you use special bash pipe result evaluation, it's always the > _last_ process in a pipe that determines its result code. > >> (Bringing back I386_DARWIN, funny thing there, is that to compile >> X client, you need Python, and the in-box one isn't new enough, >> and current doesn't build out of the box because it assumes a full >> Mac system..still working on it..) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Sun Jul 26 19:48:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:48:35 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> Message-ID: <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> I have not changed my tinderbox install on niagara for over a year and it suddenly stopped working so the problem must be with some recent commit. Note that I installed the GNU binutils way back when (over a year ago) so that things would work with 'date +%s'. Sent from my iPhone On Jul 26, 2009, at 6:07 AM, Jay K wrote: > > I'm running Tinderbox on SOLgnu now. > It fails with that error without a change and gets past the first > email if I change the date commands. > The first cvs checkout eventually failed, trying again.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Fwd: Output from "cron" command >> Date: Sun, 26 Jul 2009 03:09:59 +0000 >> >> >> Tony reverted it. I'm bringing my Solaris/sparc machine up to date >> and will try running Tinderbox. >> I will likely try with plain date and see what happens there and >> otherwise. >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Sat, 25 Jul 2009 22:00:15 +0200 >>> From: wagner at elegosoft.com >>> To: hosking at cs.purdue.edu >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>> >>> Quoting Tony Hosking : >>> >>>> I've not changed anything on my side. >>> >>> I don't understand why I missed that: >>> >>> revision 1.13 >>> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >>> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >>> let's just try plain date, based on the choices in the error message >>> ---------------------------- >>> >>> But you seem to have fixed it already: >>> >>> revision 1.14 >>> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >>> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >>> Revert to what used to work. >>> >>> Strange that it didn't show up in my first diff. >>> >>> Olaf >>> >>> >>>> >>>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>>> >>>>> I don't see how that will help us... It worked for Tony for over >>>>> a year, and nothing obvious has changed. Or did something change >>>>> on >>>>> your side, Tony (system upgrade, path setting, ...)? >>>>> >>>>> It's not good to introduce arbitrary changes now without >>>>> understanding >>>>> why it breaks. >>>>> >>>>> Olaf >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> >>>>>> Can I suggest the portable scripting language C? >>>>>> >>>>>> >>>>>> -bash-3.00$ cat date.c >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> int main() >>>>>> { >>>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>>> return 0; >>>>>> } >>>>>> -bash-3.00$ cc date.c -o ./mydate >>>>>> -bash-3.00$ ./mydate >>>>>> 1248549753 >>>>>> -bash-3.00$ pwd >>>>>> /dev2/cm3/scripts >>>>>> >>>>>> >>>>>> use that instead? >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>> >>>>>>> >>>>>>> (two occurences of that) >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>>> >>>>>>>> >>>>>>>> This line: >>>>>>>> >>>>>>>> >>>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>>> >>>>>>>> needs to more like these lines: >>>>>>>> >>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>>> >>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>>> run done." >>>>>>>> >>>>>>>> >>>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>>> 2009.07.25 12:13:54 >>>>>>>> >>>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>>> 07.25.09 12:14:33 >>>>>>>> >>>>>>>> -bash-3.00$ date +%s >>>>>>>> %s >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>>> From: wagner at elegosoft.com >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>>> >>>>>>>>> Quoting Tony Hosking : >>>>>>>>> >>>>>>>>>> Perhaps I am confusing with the original change I made for >>>>>>>>>> 1.10 to the >>>>>>>>>> parameter to the "date" command. >>>>>>>>>> >>>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>>> properly. It's been a long time since I've seen a sane >>>>>>>>>> tinderbox run >>>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>>> >>>>>>>>> I broke the last one yesterday with $() (fixed soon >>>>>>>>> afterwards), but >>>>>>>>> the one before succeeded: >>>>>>>>> >>>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>>> >>>>>>>>> I was hoping to get a green build from one of your systems >>>>>>>>> today >>>>>>>>> (big-endian, different architecture) to finally fix the RC2 >>>>>>>>> tag. >>>>>>>>> But if you cannot send your results to the tinderbox that >>>>>>>>> will be >>>>>>>>> difficult :-/ I really don't understand why that should have >>>>>>>>> stopped >>>>>>>>> working. >>>>>>>>> >>>>>>>>> The error below seems to be that the reported start time is >>>>>>>>> 0, and >>>>>>>>> that cannot be according to the source. Could you set -x at >>>>>>>>> the start >>>>>>>>> of the tinderbox script and try again? >>>>>>>>> >>>>>>>>> Jay, can you think of anything you have changed that may >>>>>>>>> cause Tony's >>>>>>>>> problem? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>>> -- Tony (not mobile) >>>>>>>>> :-) >>>>>>>>> >>>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>>> >>>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>>> >>>>>>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>>>>>> ago. Can >>>>>>>>>>>> someone restore? >>>>>>>>>>> >>>>>>>>>>> Hi Tony, >>>>>>>>>>> >>>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>> *************** >>>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>>> date 'date +%s'" >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: >>>>>>>>>>> $STARTTIME >>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>>> >>>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>>> >>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>> Jul-09 >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>> *************** >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>>> >>>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>>> *************** >>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did >>>>>>>>>>> you change >>>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>> >>>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>>> >>>>>>>>>>>>> produced the following output: >>>>>>>>>>>>> >>>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>>> >>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>>>>>> log.txt >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: >>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>> clock >>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>> time. >>>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>>>>>> minutes) >>>>>>>>>>>>> >>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023- >>>>>>>>>>>>> tVaq2V ... >>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>> *.tgz >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>> >>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>>> >>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>>>>>> log.txt >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: >>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>> clock >>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>> time. >>>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>>> >>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032- >>>>>>>>>>>>> xba4dW ... >>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>> >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>> *.tgz >>>>>>>>>>>>> >>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>>> 45 86 95 >>>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>>> Sitz: Berlin >>>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>>> IdNr: >>>>>>>>>>> DE163214194 >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wag >>>>>>>>> ner | Sitz: Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>> IdNr: DE163214194 >>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Si >>>>> tz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> From hosking at cs.purdue.edu Sun Jul 26 19:50:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:50:34 -0400 Subject: [M3devel] CM3 release engineering status In-Reply-To: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> References: <20090726124949.nw01db8v5k440kow@mail.elegosoft.com> Message-ID: <47F8AD91-A3A4-41F6-BB4C-4705BB2DD5DB@cs.purdue.edu> +I386_DARWIN right? Sent from my iPhone On Jul 26, 2009, at 6:49 AM, Olaf Wagner wrote: > Here's the current status: > > * release branch created for 5.8 > * Hudson continuous integration and Tinderbox default checkout > changed to the release branch by default (instances out of my > control) > * end of code freeze on main trunk (seems it never crossed the 0 > degree > Celsius boundary anyway :-) > * commit restriction for the release branch: > - contact me for including changes there > - needed: CVS start and end tag exactly identifying the change set > to be included > * reviewed all package test failures and fixed them (for FreeBSD4 and > AMD64_LINUX) > * only known good target platforms currently are FreeBSD4 and > AMD64_LINUX > * need status for at least LINUXLIBC6, NT386, SOLgnu additionally > * will try to setup more regression testing under my control during > the next week(s) > * RC2 postponed until end of next week... hopefully we'll know more > then > > see also https://projects.elego.de/cm3/roadmap > and http://hudson.modula3.com:8080/view/cm3/ > > Thanks for your attention and cooperation, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Sun Jul 26 19:57:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 13:57:07 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: Message-ID: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Stack overflow? And yes, I have seen deep recursions like that. What happens if you use a deeper stack? Sent from my iPhone On Jul 26, 2009, at 8:48 AM, Jay K wrote: > > Ok here is the formsedit crash. > This is on SOLgnu. I have also seen it on either PPC_DARWIN or > PPC_LINUX. > I can try those again. > > > It doesn't happen every time, but some large fraction, like maybe > half. > I changed the SIGsEGV to an assertion failure. > > > -bash-3.00$ export DISPLAY=192.168.1.120:0.0 > -bash-3.00$ ./formsedit > > *** > *** runtime error: > *** failed. > *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 > *** > Abort (core dumped) > > You can't debug it live because you keep getting interrupted by sig > usr2. > > -bash-3.00$ dbx formsedit core > > t at 1 (l at 1) terminated by signal KILL (Killed) > 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! > 0xfe3c00a4 > > These statements from the debugger about main/AddUnit don't make > sense to me. > > Current function is main > 13 RTLinker__AddUnit (FormsEdit_M3); > > (dbx) where > current thread: t at 1 > [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 > [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 > [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xfe4680b8 > [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at > 0xfe467ca0 > [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at > 0xfefa5adc > > Does the code really recurse like this? > > [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, > 0xffbf9ca0, 0xfe4a5d > 00, 0xfef48180), at 0xfef48520 > [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, > 0xff000000, 0x0, 0x0 > ), at 0xff046ea4 > [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, > 0xffbf9e48, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, > 0xffbf9f18, 0 > x0, 0xff0437d8), at 0xff043864 > [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, > 0xffbfa0a8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, > 0xffbfa238, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, > 0xffbfa3c8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, > 0xffbfa558, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, > 0xffbfa6e8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, > 0xffbfa878, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, > 0xffbfaa08, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, > 0xffbfab98, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, > 0xffbfad28, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, > 0xffbfaeb8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, > 0xffbfb048, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, > 0xffbfb1d8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, > 0xffbfb368, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, > 0xffbfb4f8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, > 0xffbfb688, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, > 0xffbfb818, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, > 0xffbfb9a8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, > 0xffbfbb38, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, > 0xffbfbcc8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, > 0xffbfbe58, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, > 0xffbfbfe8, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, > 0xffbfc178, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, > 0xffbfc308, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, > 0x0, 0x0), > at 0xff046ea4 > [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, > 0xffbfc498, > 0x0, 0xfefbcf58), at 0xfefbcf84 > [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, > 0xfe1b2000, 0x6b170 > , 0x0), at 0xff046ea4 > [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, > 0xff000000, > 0x0, 0x0), at 0xff191d20 > [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b27 > 0, 0x0), at 0xfefb6a38 > [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, > 0xfe1b2000, > 0xfe4a5d00, 0x0), at 0xfefbc9f4 > [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b290, 0x0), at 0xfefbc9f4 > [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b2b > 0, 0x0), at 0xfefb6a38 > [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, > 0xfe1b2000, > 0xfe4a5d00, 0x0), at 0xfefbc9f4 > [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b2d0, 0x0), at 0xfefbc9f4 > [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6af7 > 0, 0x0), at 0xfefb6a38 > [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, > 0xff000000, > 0x0, 0x0), at 0xfefbc9f4 > [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b33 > 0, 0x0), at 0xfefb6a38 > [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b698, 0x0), at 0xfefbc9f4 > [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, > 0xfe1b2000, 0x6b69 > 8, 0x0), at 0xfefbc9f4 > [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, > 0xfe1b2000, 0xf > e4a5d00, 0x0), at 0xfefeb348 > [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b6b8, 0x0), at 0xfefbc9f4 > [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, > 0xff000000, 0x0, 0x > 0), at 0xff157730 > [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b7f > 8, 0x0), at 0xfefb6a38 > [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b858, 0x0), at 0xfefbc9f4 > [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, > 0x0, 0x0), at > 0xfefb6a38 > [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b858, 0x0), at 0xfefbc9f4 > [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, > 0xff000000, 0x0 > , 0x0), at 0xff18d2ec > [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, > 0xfe1b2000, 0x6b87 > 8, 0x0), at 0xfefb6a38 > [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b898, 0x0), at 0xfefbc9f4 > [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, > 0xfe1b2000, 0x6b89 > 8, 0x0), at 0xfefbc9f4 > [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, > 0xfe1b2000, 0x6 > b8b8, 0x0), at 0xfefeb348 > [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, > 0x20, 0xffbfd > b20), at 0xfefb6a38 > [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, > 0xfe1b2000, > 0x6b8b8, 0x0), at 0xfefbc9f4 > [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xff01f884 > [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, > 0xfe1b2000, > 0x6b8d8, 0x0), at 0xfefbc9f4 > [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4 > a5d00, 0x0), at 0xff19e338 > [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, > 0xfe1b2000, > 0x60338, 0x0), at 0xfefbc9f4 > [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, > 0xfe1b2000, 0xfe4a5d > 00, 0x0), at 0xfeff6db4 > [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, > 0xff000000, 0x0, 0 > x0), at 0xfefb6a38 > [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, > 0xfe1b2000 > , 0x6e5a0, 0x0), at 0xfefbc9f4 > (dbx) > (dbx) threads >> t at 1 a l at 1 ?() LWP suspended in __lwp_park() > t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in > ___nanosleep > () > t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 > in __lwp_pa > rk() > t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in > ___nanosleep > () > t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 > in __lwp_pa > rk() > t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 > in __lwp_pa > rk() > t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 > in __lwp_pa > rk() > o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in > __lwp_kill( > ) > t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 > in __lwp_pa > rk() > (dbx) > > > The crashing thread: > > (dbx) thread t at 27 > t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 > 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xfe3c11f4 > (dbx) where > current thread: t at 27 > =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 > [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at > 0xfe35fdd8 > [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at > 0xfe33fff8 > [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at > 0xfe46255c > [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at > 0xfe4529c8 > [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, > 0xfddf0900), at 0x > fe44f2e4 > [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, > 0xfe4b4d90, 0xff2 > 50434), at 0xfe44ee5c > [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, > 0x100000), > at 0xfe44fa0c > [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 > ), > at 0xfe44f590 > [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, > 0xfffffff8, 0x0, > 0xfdc53131), at 0xfe44f44c > [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, > 0x0), at 0xfe46 > 470c > [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 > ), > at 0xfe44f680 > [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, > 0xfffffff8, 0x0, > 0xfdc53661), at 0xfe44f44c > [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, > 0x0, 0xfdc538 > e1), at 0xfe46470c > [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, > 0xfdc53a40, 0xfdc539 > 2c, 0xfdc53928), at 0xfe42ffe0 > [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, > 0xfdc53a40), a > t 0xff141d64 > > (too many frames for an assertion failure imho!) > > > [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, > 0x1000, 0x0, > 0x0), at 0xff13dda4 > [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, > 0xff000000, 0x0, > 0x0), at 0xff13d9e8 > [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, > 0xfddf0800, > 0x69da0, 0x0), at 0xff140730 > [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, > 0xff000000, 0xff00000 > 0, 0x0, 0x1), at 0xff1407d0 > [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, > 0xfdd221bc), a > t 0xfefb8f04 > [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at > 0xfefc5170 > [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, > 0xfddf0800, 0x90 > 410, 0x0), at 0xfefc45a8 > [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at > 0xfefc4674 > [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at > 0xfe46bc00 > [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, > 0xfe46b740, 0x1) > , at 0xfe46b790 > (dbx) > > > - Jay From jay.krell at cornell.edu Sun Jul 26 19:57:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 17:57:14 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> Message-ID: X clients as in the X client libraries themselves Xlib.so et. al. -- as opposed to the X server. Actually apparently Xlib has been partly replaced by xcb, X C bindings. It is not a Modula-3 thing. But it is interesting imho. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Sun, 26 Jul 2009 13:44:39 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] Tinderbox/Hudson > > It did not used to be required that to build X clients on I386_DARWIN > you needed Python. What changed? > > Sent from my iPhone > > On Jul 26, 2009, at 5:17 AM, Olaf Wagner wrote: > >> Quoting Jay K : >> >>> - The links to my Tinderbox test results don't work. >>> >>> - Why are my Tinderbox status usually yellow even though the logs >>> look ok? >>> Due the missing test results? >>> >>> - I do already have Hudson server running OpenBSD/x86, that was >>> easy, not configured yet (still cross building cm3 and will try a >>> Tinderbox run first instead.) >>> >>> LINUXLIBC6 is yellow, but this looks ok: >>> >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248586756.14190 >>> >>> Do they have to be more recent? Or need last release and last ok? >>> I only do last ok. You don't have last release for AMD64_LINUX, it >>> doesn't exist, but are green. >>> Maybe two separate builds are needed? >>> >>> SPARC32_LINUX is yellow but it also looks ok. >>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248433196.25517 >> >> Tinderbox shows running builds that haven't complete yet in yellow. >> Results are either green, red, or orange. So the result transfer to >> the server may have failed. >> >>> The most recent completed PPC_LINUX failed to get much of the >>> source tree in the CVS checkout. That happens often. I should >>> probably put in a retry or something.. >> >> No. You should probably do something about your network connection ;-) >> >> BTW, the exit you put in after the cvs checkout won't work this way. >> Unless you use special bash pipe result evaluation, it's always the >> _last_ process in a pipe that determines its result code. >> >>> (Bringing back I386_DARWIN, funny thing there, is that to compile >>> X client, you need Python, and the in-box one isn't new enough, >>> and current doesn't build out of the box because it assumes a full >>> Mac system..still working on it..) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ >> any >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be >> rlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> From hosking at cs.purdue.edu Sun Jul 26 20:00:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:00:14 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <200907261557.n6QFvTIu008442@niagara.cs.purdue.edu> Message-ID: I haven't digested this closely, but here is the latest niagara tinderbox log with +x. Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: July 26, 2009 11:57:29 AM EDT > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > + trap cleanup 1 2 3 6 > + [ -z cm3.build ] > + . cm3.build > PROJECT=cm3 > TREENAME=cm3 > BUILD_REL=rel > BUILD_REL_NAME=rel > REGRESSION_SCRIPTS_DIR=regression-scripts > + [ rel = rel ] > BUILD_REL_NAME=release > + hostname > + [ -f ~/cm3/niagara.cs.purdue.edu.conf ] > CVSROOT=:ext:modula3.elegosoft.com:/usr/cvs > + cvs -d :ext:modula3.elegosoft.com:/usr/cvs checkout -A -d > regression-scripts cm3/scripts/regression/defs.sh > U regression-scripts/defs.sh > + test -r regression-scripts/defs.sh > + . regression-scripts/defs.sh > + sed -e s/\..*//+ hostname > > TESTHOSTNAME=niagara > HTMP=/homes/hosking/tmp/cm3/niagara > + tr -d+ date\n -u > +%Y-%m-%d-%H-%M-%S > DS=2009-07-26-10-30-05 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > COVERSION=-P -r release_branch_cm3_5_8 > LASTREL=5.4.0 > INSTBASE=/homes/hosking/work/cm3-inst/niagara > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + test x != x > CM3CVSUSER_AT= > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > WWWSERVER=birch.elegosoft.com > RLOG=/homes/hosking/tmp/cm3/niagara/cm3-rlog-2009-07-26-10-30-05 > CM3_NKEEP=7 > + uname > UNAME=SunOS > + uname -m > UNAMEM=sun4v > TMP=/tmp > TMPDIR=/tmp > + [ ! -d /tmp ] > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > M3TOUT=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-10-30-05.stdout > M3TERR=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-10-30-05.stderr > CM3_VERSION=* > CM3_SNAPSHOT=/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu- > *-2009-07-26-10-30-05.tgz > HTML_REPORT=/tmp/cm3-pkg-report-SOLgnu-2009-07-26-10-30-05.html > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_LOC=/homes/hosking/work > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_URL=http://modula3.elegosoft.com/cm3 > + echo TESTHOSTNAME=niagara > TESTHOSTNAME=niagara > + echo WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05 > + echo LASTREL=5.4.0 > LASTREL=5.4.0 > + echo INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > + echo INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > + echo INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > + echo INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + echo CM3_OSTYPE=POSIX > CM3_OSTYPE=POSIX > + echo CM3_TARGET=SOLgnu > CM3_TARGET=SOLgnu > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSSERVER=birch.elegosoft.com > CM3CVSSERVER=birch.elegosoft.com > + echo CM3CVSROOT=birch.elegosoft.com:/usr/cvs > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > + echo BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSUSER= > CM3CVSUSER= > + type cvs > + true > + echo testing ssh birch.elegosoft.com.. > testing ssh birch.elegosoft.com.. > + ssh birch.elegosoft.com true > + echo ssh birch.elegosoft.com ok > ssh birch.elegosoft.com ok > + true > + [ ! -d /homes/hosking/tmp/cm3/niagara ] > + uname -s > + uname -r > TESTMACHINE=SunOS 5.10 > TTT=SOLgnu SunOS 5.10 niagara > BUILDNAME=SOLgnu SunOS 5.10 niagara release-build > + [ -z cm3 -o -z cm3 ] > BUILDNAME=SOLgnu SunOS 5.10 niagara release-build > + echo Building cm3. > Building cm3. > + echo Tinderbox Tree: "cm3" > Tinderbox Tree: "cm3" > + echo Buildname: "SOLgnu SunOS 5.10 niagara release-build" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > + echo > > + date +%Y%m%d-%H%M%S > NAME=build-cm3-20090726-063007 > + date +%s > STARTTIME=1248604207 > BUILDDIR_ROOT=/tmp > + mktemp -d /tmp/build-cm3-20090726-063007-XXXXXX > BUILDDIR_BASE=/tmp/build-cm3-20090726-063007-yIa4JX > BUILDDIR=/tmp/build-cm3-20090726-063007-yIa4JX/build > LOG=/tmp/build-cm3-20090726-063007-yIa4JX/log.txt > T=/tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + mkdir /tmp/build-cm3-20090726-063007-yIa4JX/build > + [ ! -d /tmp/build-cm3-20090726-063007-yIa4JX/build ] > + echo creating log file /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > creating log file /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + touch /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + [ ! -w /tmp/build-cm3-20090726-063007-yIa4JX/log.txt ] > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo > > + echo --- > --- > + echo > > + echo checkout, compile and test of cm3 ... > checkout, compile and test of cm3 ... > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 06:30:07 -- checkout in progress. > 2009.07.26 06:30:07 -- checkout in progress. > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248604207 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [start checkout 2009.07.26 06:30:09] > [start checkout 2009.07.26 06:30:09] > + echo cd /tmp/build-cm3-20090726-063007-yIa4JX/build > cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + do_checkout > CHECKOUT_RETURN=0 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo cvs return value: 0 > + date +%Y.%m.%d %H:%M:%S > cvs return value: 0 > + echo [end checkout 2009.07.26 06:45:02] > [end checkout 2009.07.26 06:45:02] > + echo CHECKOUT_RETURN = 0 > CHECKOUT_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248605102 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo -- > -- > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 06:45:12 -- compile in progress. > 2009.07.26 06:45:12 -- compile in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start compile 2009.07.26 06:45:12] > [start compile 2009.07.26 06:45:12] > + do_compile > COMPILE_RETURN=0 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + echo compile return value: 0 > compile return value: 0 > + date +%Y.%m.%d %H:%M:%S > + echo [end compile 2009.07.26 08:24:29] > [end compile 2009.07.26 08:24:29] > + echo COMPILE_RETURN = 0 > COMPILE_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > building 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=building > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > building -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248611069 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 08:24:34 -- tests in progress. > 2009.07.26 08:24:34 -- tests in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start run-tests 2009.07.26 08:24:34] > [start run-tests 2009.07.26 08:24:34] > + echo cd /tmp/build-cm3-20090726-063007-yIa4JX/build > cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + cd /tmp/build-cm3-20090726-063007-yIa4JX/build > + do_tests > TESTS_RETURN=511 > + cat /tmp/build-cm3-20090726-063007-yIa4JX/tmp-25355 > + tee -a /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [end run-tests 2009.07.26 10:39:00] > [end run-tests 2009.07.26 10:39:00] > + echo TESTS_RETURN = 511 > TESTS_RETURN = 511 > + [ 511 != 0 ] > + + echotee *** TESTS FAILED-a > /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > *** TESTS FAILED > + mail_buildlog test_failed > + [ -z test_failed ] > TMP_LOG=/tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + [ -z /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara release-build > test_failed 1248604207 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara release-build > STATUS=test_failed > STARTTIME=1248604207 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara release-build -o -z > test_failed -o -z 1248604207 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248604207 > + date +%s > + echo tinderbox: timenow: 1248619141 > + echo tinderbox: status: test_failed > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara release-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-063007-yIa4JX/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temp > + true > + + catssh /tmp/build-cm3-20090726-063007-yIa4JX/build/ > mail_temptinderbox.elego.de > sudo -u tinderbox /usr/local/tinderbox/tinderbox-cgi/ > processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-063007-yIa4JX/build/mail_temp > + cleanup > + echo removing build tree /tmp/build-cm3-20090726-063007-yIa4JX ... > removing build tree /tmp/build-cm3-20090726-063007-yIa4JX ... > + cd /tmp > + rm -rf /tmp/build-cm3-20090726-063007-yIa4JX > + do_cleanup > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > + exit 1 > + trap cleanup 1 2 3 6 > + [ -z cm3.build ] > + . cm3.build > PROJECT=cm3 > TREENAME=cm3 > BUILD_REL=lastok > BUILD_REL_NAME=lastok > REGRESSION_SCRIPTS_DIR=regression-scripts > + [ lastok = rel ] > + hostname > + [ -f ~/cm3/niagara.cs.purdue.edu.conf ] > CVSROOT=:ext:modula3.elegosoft.com:/usr/cvs > + cvs -d :ext:modula3.elegosoft.com:/usr/cvs checkout -A -d > regression-scripts cm3/scripts/regression/defs.sh > + test -r regression-scripts/defs.sh > + . regression-scripts/defs.sh > + sed -e s/\..*// > + hostname > TESTHOSTNAME=niagara > HTMP=/homes/hosking/tmp/cm3/niagara > + tr+ date-d -u\n +%Y-%m-%d-%H-%M-%S > > DS=2009-07-26-14-41-31 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > COVERSION=-P -r release_branch_cm3_5_8 > LASTREL=5.4.0 > INSTBASE=/homes/hosking/work/cm3-inst/niagara > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + test x != x > CM3CVSUSER_AT= > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > WWWSERVER=birch.elegosoft.com > RLOG=/homes/hosking/tmp/cm3/niagara/cm3-rlog-2009-07-26-14-41-31 > CM3_NKEEP=7 > + uname > UNAME=SunOS > + uname -m > UNAMEM=sun4v > TMP=/tmp > TMPDIR=/tmp > + [ ! -d /tmp ] > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > M3TOUT=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-14-41-31.stdout > M3TERR=/homes/hosking/tmp/cm3/niagara/ > m3tests-2009-07-26-14-41-31.stderr > CM3_VERSION=* > CM3_SNAPSHOT=/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu- > *-2009-07-26-14-41-31.tgz > HTML_REPORT=/tmp/cm3-pkg-report-SOLgnu-2009-07-26-14-41-31.html > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_LOC=/homes/hosking/work > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_URL=http://modula3.elegosoft.com/cm3 > + echo TESTHOSTNAME=niagara > TESTHOSTNAME=niagara > + echo WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > WS=/homes/hosking/work/cm3-ws/niagara-2009-07-26-14-41-31 > + echo LASTREL=5.4.0 > LASTREL=5.4.0 > + echo INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > + echo INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > + echo INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > + echo INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > + echo CM3_OSTYPE=POSIX > CM3_OSTYPE=POSIX > + echo CM3_TARGET=SOLgnu > CM3_TARGET=SOLgnu > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSSERVER=birch.elegosoft.com > CM3CVSSERVER=birch.elegosoft.com > + echo CM3CVSROOT=birch.elegosoft.com:/usr/cvs > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > + echo BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > + echo CM3CVSUSER= > CM3CVSUSER= > + type cvs > + true > + echo testing ssh birch.elegosoft.com.. > testing ssh birch.elegosoft.com.. > + ssh birch.elegosoft.com true > + echo ssh birch.elegosoft.com ok > ssh birch.elegosoft.com ok > + true > + [ ! -d /homes/hosking/tmp/cm3/niagara ] > + uname -s > + uname -r > TESTMACHINE=SunOS 5.10 > TTT=SOLgnu SunOS 5.10 niagara > BUILDNAME=SOLgnu SunOS 5.10 niagara lastok-build > + [ -z cm3 -o -z cm3 ] > BUILDNAME=SOLgnu SunOS 5.10 niagara lastok-build > + echo Building cm3. > Building cm3. > + echo Tinderbox Tree: "cm3" > Tinderbox Tree: "cm3" > + echo Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > + echo > > + date +%Y%m%d-%H%M%S > NAME=build-cm3-20090726-104133 > + date +%s > STARTTIME=1248619293 > BUILDDIR_ROOT=/tmp > + mktemp -d /tmp/build-cm3-20090726-104133-XXXXXX > BUILDDIR_BASE=/tmp/build-cm3-20090726-104133-R0aGhi > BUILDDIR=/tmp/build-cm3-20090726-104133-R0aGhi/build > LOG=/tmp/build-cm3-20090726-104133-R0aGhi/log.txt > T=/tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + mkdir /tmp/build-cm3-20090726-104133-R0aGhi/build > + [ ! -d /tmp/build-cm3-20090726-104133-R0aGhi/build ] > + echo creating log file /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > creating log file /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + touch /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + [ ! -w /tmp/build-cm3-20090726-104133-R0aGhi/log.txt ] > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo > > + echo --- > --- > + echo > > + echo checkout, compile and test of cm3 ... > checkout, compile and test of cm3 ... > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 10:41:34 -- checkout in progress. > 2009.07.26 10:41:34 -- checkout in progress. > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248619294 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [start checkout 2009.07.26 10:41:36] > [start checkout 2009.07.26 10:41:36] > + echo cd /tmp/build-cm3-20090726-104133-R0aGhi/build > cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + do_checkout > CHECKOUT_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a + /tmp/build-cm3-20090726-104133-R0aGhi/log.txtecho > cvs return value: 0 > + date +%Y.%m.%d %H:%M:%S > cvs return value: 0 > + echo [end checkout 2009.07.26 10:56:34] > [end checkout 2009.07.26 10:56:34] > + echo CHECKOUT_RETURN = 0 > CHECKOUT_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248620194 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp+ ssh > tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo -- > -- > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 10:56:36 -- compile in progress. > 2009.07.26 10:56:36 -- compile in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start compile 2009.07.26 10:56:36] > [start compile 2009.07.26 10:56:36] > + do_compile > COMPILE_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + echo compile return value: 0 > compile return value: 0 > + date +%Y.%m.%d %H:%M:%S > + echo [end compile 2009.07.26 11:54:10] > [end compile 2009.07.26 11:54:10] > + echo COMPILE_RETURN = 0 > COMPILE_RETURN = 0 > + [ 0 != 0 ] > + mail_buildlog building > + [ -z building ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > building 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=building > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > building -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248623650 > + echo tinderbox: status: building > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp+ ssh > tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 11:54:14 -- tests in progress. > 2009.07.26 11:54:14 -- tests in progress. > + date +%Y.%m.%d %H:%M:%S > + echo [start run-tests 2009.07.26 11:54:14] > [start run-tests 2009.07.26 11:54:14] > + echo cd /tmp/build-cm3-20090726-104133-R0aGhi/build > cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + cd /tmp/build-cm3-20090726-104133-R0aGhi/build > + do_tests > TESTS_RETURN=0 > + cat /tmp/build-cm3-20090726-104133-R0aGhi/tmp-4136 > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo [end run-tests 2009.07.26 11:54:14] > [end run-tests 2009.07.26 11:54:14] > + echo TESTS_RETURN = 0 > TESTS_RETURN = 0 > + [ 0 != 0 ] > + tee -a /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + date +%Y.%m.%d %H:%M:%S > + echo 2009.07.26 11:54:14 -- checkout, compile and test run done. > 2009.07.26 11:54:14 -- checkout, compile and test run done. > + echo > > + echo --- > --- > + echo > > + mail_buildlog success > + [ -z success ] > TMP_LOG=/tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + [ -z /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp ] > + tinderbox_header cm3 SOLgnu SunOS 5.10 niagara lastok-build > success 1248619293 > TREE_NAME=cm3 > BUILD_NAME=SOLgnu SunOS 5.10 niagara lastok-build > STATUS=success > STARTTIME=1248619293 > + [ -z cm3 -o -z SOLgnu SunOS 5.10 niagara lastok-build -o -z > success -o -z 1248619293 ] > + echo > + echo tinderbox: tree: cm3 > + echo tinderbox: starttime: 1248619293 > + date +%s > + echo tinderbox: timenow: 1248623654 > + echo tinderbox: status: success > + echo tinderbox: buildname: SOLgnu SunOS 5.10 niagara lastok-build > + echo tinderbox: errorparser: unix > + echo tinderbox: END > + echo > + cat /tmp/build-cm3-20090726-104133-R0aGhi/log.txt > + tinderbox_mailer /tmp/build-cm3-20090726-104133-R0aGhi/build/ > mail_temp > + true > + cat /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp + > ssh tinderbox.elego.de sudo -u tinderbox /usr/local/tinderbox/ > tinderbox-cgi/processmail_builds.cgi > + [ 0 != 0 ] > + rm -f /tmp/build-cm3-20090726-104133-R0aGhi/build/mail_temp > + cleanup > + echo removing build tree /tmp/build-cm3-20090726-104133-R0aGhi ... > removing build tree /tmp/build-cm3-20090726-104133-R0aGhi ... > + cd /tmp > + rm -rf /tmp/build-cm3-20090726-104133-R0aGhi > + do_cleanup > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > + echo done. > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 26 20:03:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:03:30 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> References: <200907251030.n6PAUZdL024700@niagara.cs.purdue.edu> <1BE4DF03-DB8A-4F58-A60E-33963931D7D9@cs.purdue.edu> <20090725200026.d6rf9t5dusw80cwc@mail.elegosoft.com> <95AD32E0-E80D-4DFB-B23D-9749D4E9D662@cs.purdue.edu> <20090725204438.n75gjjnlq8oggw0c@mail.elegosoft.com> <20090725215213.1qwpo3ldwk0ss084@mail.elegosoft.com> <20090725220015.imi3floiec0wo4sg@mail.elegosoft.com> <0EAFD56D-B560-4CCE-9277-89A98E0E3063@cs.purdue.edu> Message-ID: The error is coming from the server. Nothing in the CVS tree validates timenow or prints this error. # function used to send results to a tinderbox server. # per default it is empty so the build-log will just be output to stdout. tinderbox_mailer() { true # needed if function is empty without this... # to report to the elego tinderbox host, check README and uncomment this: #cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox \ #/usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" } It is that /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi. Whether you/we started feeding it different data somehow I don't know. However I don't have GNU date so I made it work with whatever is the Solaris default. I'm inclined to move on, but I agree it is not understood. Maybe put in which date type data before the runs? - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 13:48:35 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > I have not changed my tinderbox install on niagara for over a year and > it suddenly stopped working so the problem must be with some recent > commit. Note that I installed the GNU binutils way back when (over a > year ago) so that things would work with 'date +%s'. > > Sent from my iPhone > > On Jul 26, 2009, at 6:07 AM, Jay K wrote: > >> >> I'm running Tinderbox on SOLgnu now. >> It fails with that error without a change and gets past the first >> email if I change the date commands. >> The first cvs checkout eventually failed, trying again.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>> Date: Sun, 26 Jul 2009 03:09:59 +0000 >>> >>> >>> Tony reverted it. I'm bringing my Solaris/sparc machine up to date >>> and will try running Tinderbox. >>> I will likely try with plain date and see what happens there and >>> otherwise. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 25 Jul 2009 22:00:15 +0200 >>>> From: wagner at elegosoft.com >>>> To: hosking at cs.purdue.edu >>>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>> >>>> Quoting Tony Hosking : >>>> >>>>> I've not changed anything on my side. >>>> >>>> I don't understand why I missed that: >>>> >>>> revision 1.13 >>>> date: 2009-07-25 19:29:42 +0000; author: jkrell; state: Exp; lines: >>>> +1 -1; commitid: 2k2ef7HTLZ9SZ7Xt; >>>> let's just try plain date, based on the choices in the error message >>>> ---------------------------- >>>> >>>> But you seem to have fixed it already: >>>> >>>> revision 1.14 >>>> date: 2009-07-25 19:56:01 +0000; author: hosking; state: Exp; >>>> lines: +1 -1; commitid: yRpWy2mygKpT88Xt; >>>> Revert to what used to work. >>>> >>>> Strange that it didn't show up in my first diff. >>>> >>>> Olaf >>>> >>>> >>>>> >>>>> On 25 Jul 2009, at 15:52, Olaf Wagner wrote: >>>>> >>>>>> I don't see how that will help us... It worked for Tony for over >>>>>> a year, and nothing obvious has changed. Or did something change >>>>>> on >>>>>> your side, Tony (system upgrade, path setting, ...)? >>>>>> >>>>>> It's not good to introduce arbitrary changes now without >>>>>> understanding >>>>>> why it breaks. >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting Jay K : >>>>>> >>>>>>> >>>>>>> Can I suggest the portable scripting language C? >>>>>>> >>>>>>> >>>>>>> -bash-3.00$ cat date.c >>>>>>> #include >>>>>>> #include >>>>>>> #include >>>>>>> int main() >>>>>>> { >>>>>>> printf("%lu\n", (unsigned long)time(NULL)); >>>>>>> return 0; >>>>>>> } >>>>>>> -bash-3.00$ cc date.c -o ./mydate >>>>>>> -bash-3.00$ ./mydate >>>>>>> 1248549753 >>>>>>> -bash-3.00$ pwd >>>>>>> /dev2/cm3/scripts >>>>>>> >>>>>>> >>>>>>> use that instead? >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>> Date: Sat, 25 Jul 2009 19:19:57 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>> >>>>>>>> >>>>>>>> (two occurences of that) >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: wagner at elegosoft.com; hosking at cs.purdue.edu >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: RE: [M3devel] Fwd: Output from "cron" command >>>>>>>>> Date: Sat, 25 Jul 2009 19:19:11 +0000 >>>>>>>>> >>>>>>>>> >>>>>>>>> This line: >>>>>>>>> >>>>>>>>> >>>>>>>>> echo tinderbox: timenow: `date +%s` >>>>>>>>> >>>>>>>>> needs to more like these lines: >>>>>>>>> >>>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout in progress." >>>>>>>>> >>>>>>>>> echo "`date '+%Y.%m.%d %H:%M:%S'` -- checkout, compile and test >>>>>>>>> run done." >>>>>>>>> >>>>>>>>> >>>>>>>>> -bash-3.00$ date '+%Y.%m.%d %H:%M:%S' >>>>>>>>> 2009.07.25 12:13:54 >>>>>>>>> >>>>>>>>> -bash-3.00$ date '+%m.%d.%y %H:%M:%S' >>>>>>>>> 07.25.09 12:14:33 >>>>>>>>> >>>>>>>>> -bash-3.00$ date +%s >>>>>>>>> %s >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> Date: Sat, 25 Jul 2009 20:44:38 +0200 >>>>>>>>>> From: wagner at elegosoft.com >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] Fwd: Output from "cron" command >>>>>>>>>> >>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>> >>>>>>>>>>> Perhaps I am confusing with the original change I made for >>>>>>>>>>> 1.10 to the >>>>>>>>>>> parameter to the "date" command. >>>>>>>>>>> >>>>>>>>>>> In any case, something changed so that my scripts did not run >>>>>>>>>>> properly. It's been a long time since I've seen a sane >>>>>>>>>>> tinderbox run >>>>>>>>>>> for Solaris -- will things be stabilising soon? >>>>>>>>>> >>>>>>>>>> I broke the last one yesterday with $() (fixed soon >>>>>>>>>> afterwards), but >>>>>>>>>> the one before succeeded: >>>>>>>>>> >>>>>>>>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248363757.16203 >>>>>>>>>> >>>>>>>>>> I was hoping to get a green build from one of your systems >>>>>>>>>> today >>>>>>>>>> (big-endian, different architecture) to finally fix the RC2 >>>>>>>>>> tag. >>>>>>>>>> But if you cannot send your results to the tinderbox that >>>>>>>>>> will be >>>>>>>>>> difficult :-/ I really don't understand why that should have >>>>>>>>>> stopped >>>>>>>>>> working. >>>>>>>>>> >>>>>>>>>> The error below seems to be that the reported start time is >>>>>>>>>> 0, and >>>>>>>>>> that cannot be according to the source. Could you set -x at >>>>>>>>>> the start >>>>>>>>>> of the tinderbox script and try again? >>>>>>>>>> >>>>>>>>>> Jay, can you think of anything you have changed that may >>>>>>>>>> cause Tony's >>>>>>>>>> problem? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>>> -- Tony (not mobile) >>>>>>>>>> :-) >>>>>>>>>> >>>>>>>>>>> On 25 Jul 2009, at 14:00, Olaf Wagner wrote: >>>>>>>>>>> >>>>>>>>>>>> Quoting Tony Hosking : >>>>>>>>>>>> >>>>>>>>>>>>> This is an old error for Solaris that I fixed a long time >>>>>>>>>>>>> ago. Can >>>>>>>>>>>>> someone restore? >>>>>>>>>>>> >>>>>>>>>>>> Hi Tony, >>>>>>>>>>>> >>>>>>>>>>>> as far as I can see nothing has changed regarding STARTTIME: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>>> 'STARTTIME| date' >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>>> *************** >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): NAME="build-${PROJECT}-`date >>>>>>>>>>>> '+%Y %m%d-%H%M%S'`" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): STARTTIME="$4" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): if [ -z "${TREE_NAME}" -o -z >>>>>>>>>>>> "$ {BUILD_NAME}" -o -z "${STATUS}" -o -z "${STARTTIME}" ] >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo " >>>>>>>>>>>> date 'date +%s'" >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: starttime: >>>>>>>>>>>> $STARTTIME >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): echo tinderbox: timenow: `date + %s` >>>>>>>>>>>> 1.8 (wagner 03-Feb-08): tinderbox_header "$ >>>>>>>>>>>> {TREENAME}" "${BUILDNAME}" "$1" "${STARTTIME}" >>>>>>>>>>>> 1.1 (kschleis 06-Jan-08): STARTTIME=`date +%s` >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>>> %S'` -- checkout in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start checkout `date >>>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end checkout `date >>>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>>> %H:%M: %S'` -- compile in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start compile `date >>>>>>>>>>>> '+ %Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end compile `date '+%Y. >>>>>>>>>>>> %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d >>>>>>>>>>>> %H:%M: %S'` -- tests in progress." >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[start run-tests `date >>>>>>>>>>>> '+%Y.%m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "[end run-tests `date >>>>>>>>>>>> '+%Y. %m.%d %H:%M:%S'`]" >>>>>>>>>>>> 1.10 (hosking 09-Mar-08): echo "`date '+%Y.%m.%d %H:%M: >>>>>>>>>>>> %S'` -- checkout, compile and test run done." >>>>>>>>>>>> >>>>>>>>>>>> Nothing at all has changed in these scripts in July: >>>>>>>>>>>> >>>>>>>>>>>> % cvs ann scripts/regression/tinderbox-build.sh | egrep >>>>>>>>>>>> Jul-09 >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/tinderbox-build.sh >>>>>>>>>>>> *************** >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> % cvs ann scripts/regression/cm3.bu | egrep Jul-09 >>>>>>>>>>>> cm3.build cm3.build~ >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> % cvs ann scripts/regression/cm3.build | egrep Jul-09 >>>>>>>>>>>> >>>>>>>>>>>> Annotations for scripts/regression/cm3.build >>>>>>>>>>>> *************** >>>>>>>>>>>> luthien [~/work/cm3] wagner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Perhaps I'm looking for the wrong thing. What exactly did >>>>>>>>>>>> you change >>>>>>>>>>>> long ago to make it work? I'm at a loss now. >>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> You seem to be very `mobile' lately ;-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>> >>>>>>>>>>>>>> From: Tony Hosking >>>>>>>>>>>>>> Date: July 25, 2009 5:30:35 AM CDT >>>>>>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>>>>>> Subject: Output from "cron" command >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Your "cron" job on niagara.cs.purdue.edu >>>>>>>>>>>>>> $HOME/cm3/scripts/regression/cron.sh >>>>>>>>>>>>>> >>>>>>>>>>>>>> produced the following output: >>>>>>>>>>>>>> >>>>>>>>>>>>>> U regression-scripts/defs.sh >>>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-19 >>>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>>>>>>>>>>> >>>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063023-tVaq2V/ >>>>>>>>>>>>>> log.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>>> 2009.07.25 06:30:23 -- checkout in progress. >>>>>>>>>>>>>> [Sat Jul 25 12:30:27 2009] Variable: 'tinderbox: >>>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>>> clock >>>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> variable timenow: 0, timenow: 1248517827, (-20808630.45 >>>>>>>>>>>>>> minutes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063023- >>>>>>>>>>>>>> tVaq2V ... >>>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>>> *.tgz >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> TESTHOSTNAME=niagara >>>>>>>>>>>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-07-25-10-30-30 >>>>>>>>>>>>>> LASTREL=5.4.0 >>>>>>>>>>>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/ >>>>>>>>>>>>>> rel-5.4.0 >>>>>>>>>>>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>>>>>>>>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>>>>>>>>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>>>>>>>>>>> CM3_OSTYPE=POSIX >>>>>>>>>>>>>> CM3_TARGET=SOLgnu >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSSERVER=birch.elegosoft.com >>>>>>>>>>>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>>>>>>>>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX- >>>>>>>>>>>>>> SOLgnu-5.4.0.tgz >>>>>>>>>>>>>> CM3CVSUSER= >>>>>>>>>>>>>> testing ssh birch.elegosoft.com.. >>>>>>>>>>>>>> ssh birch.elegosoft.com ok >>>>>>>>>>>>>> Building cm3. >>>>>>>>>>>>>> Tinderbox Tree: "cm3" >>>>>>>>>>>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>>>>>>>>>>> >>>>>>>>>>>>>> creating log file /tmp/build-cm3-20090725-063032-xba4dW/ >>>>>>>>>>>>>> log.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> checkout, compile and test of cm3 ... >>>>>>>>>>>>>> 2009.07.25 06:30:32 -- checkout in progress. >>>>>>>>>>>>>> [Sat Jul 25 12:30:35 2009] Variable: 'tinderbox: >>>>>>>>>>>>>> timenow:', is >>>>>>>>>>>>>> not of the form MM/DD/YY HH:MM:SS, or unix date, or your >>>>>>>>>>>>>> clock >>>>>>>>>>>>>> is set incorrectly, or the mail was delayed for a long >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> variable timenow: 0, timenow: 1248517835, >>>>>>>>>>>>>> (-20808630.5833333 minutes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Error: Sending buildlog failed! >>>>>>>>>>>>>> removing build tree /tmp/build-cm3-20090725-063032- >>>>>>>>>>>>>> xba4dW ... >>>>>>>>>>>>>> cleaning CM3 workspaces... >>>>>>>>>>>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning regression test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning m3test log files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>>>>>>>>>>> >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning snapshot files... >>>>>>>>>>>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>>>>>>>>>>>> *.tgz >>>>>>>>>>>>>> >>>>>>>>>>>>>> cleaning package reports... >>>>>>>>>>>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>>>>>>> 45 86 95 >>>>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>>>>> Sitz: Berlin >>>>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>>>> IdNr: >>>>>>>>>>>> DE163214194 >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>>> 23 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wag >>>>>>>>>> ner | Sitz: Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>>> IdNr: DE163214194 >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Si >>>>>> tz: Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> From jay.krell at cornell.edu Sun Jul 26 20:07:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:07:54 +0000 Subject: [M3devel] OpenGL on Darwin 10.4 x86 (not MacOSX)? Message-ID: Anyone gotten OpenGL working in Darwin 10.4 x86? I don't mean MacOSX. The stripped down Darwin thing. I had a heck of a time getting X libraries on the machine. I had to upgrade Python. And X has been broken into a bunch of separate pieces. And Xaw installs kind of wrong -- Xaw7.dylib, Xaw6.dylib, and Xaw.so -- .so! I changed it around to look like my PPC_LINUX machine to get past that.. Anyway, I have libGL but not some others..tried building Mesa and SGI glx. I think I'll give up. Make the system check for SYSTEM_LIBS/LIBORDER, skip packages, and not build distributions on this system. Or am I missing smoething?? I did search the web some. Haven't asked the X/Mesa people. Maybe Fink is the way? But the result won't by default be compatible with Mac OSX. - Jay From hosking at cs.purdue.edu Sun Jul 26 20:13:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:13:09 -0400 Subject: [M3devel] libz in Tinderbox? In-Reply-To: References: Message-ID: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> What needs libz? I think it is already installed but will need to log on when able to to find where it is installed. Sent from my iPhone On Jul 26, 2009, at 1:16 PM, Jay K wrote: > > Tony can you install libz? Or should we import it? Or should we > maybe probe for $HOME/lib/libz.a or somewhere else? > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 > > "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- > tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake > runtime error: file libz.a not found in /usr/lib /usr/local/lib / > lib /usr/contrib/lib /opt/lib > 22072 > > > There is also: > > Must be attached to terminal for ?am I? option > 49575 + [ niagara = birch.elegosoft.com -a = m3 ] > 49576 ./tinderbox-build.sh: test: argument expected > 49577 r4=1 > 49578 + expr 0 + 0 + 255 + 255 + 1 > 49579 + return 511 > 49580 + date +%Y.%m.%d %H:%M:%S > 49581 + echo [end run-tests 2009.07.26 10:39:00] > 49582 [end run-tests 2009.07.26 10:39:00] > 49583 *** TESTS FAILED > > > - Jay From jay.krell at cornell.edu Sun Jul 26 20:28:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:28:06 +0000 Subject: [M3devel] libz in Tinderbox? In-Reply-To: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> References: <9E746946-7DE8-4419-AA9B-6566D1BAF657@cs.purdue.edu> Message-ID: cvsup. >> "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- >> tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 14:13:09 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] libz in Tinderbox? > > What needs libz? I think it is already installed but will need to log > on when able to to find where it is installed. > > Sent from my iPhone > > On Jul 26, 2009, at 1:16 PM, Jay K wrote: > >> >> Tony can you install libz? Or should we import it? Or should we >> maybe probe for $HOME/lib/libz.a or somewhere else? >> >> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 >> >> "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- >> tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake >> runtime error: file libz.a not found in /usr/lib /usr/local/lib / >> lib /usr/contrib/lib /opt/lib >> 22072 >> >> >> There is also: >> >> Must be attached to terminal for ?am I? option >> 49575 + [ niagara = birch.elegosoft.com -a = m3 ] >> 49576 ./tinderbox-build.sh: test: argument expected >> 49577 r4=1 >> 49578 + expr 0 + 0 + 255 + 255 + 1 >> 49579 + return 511 >> 49580 + date +%Y.%m.%d %H:%M:%S >> 49581 + echo [end run-tests 2009.07.26 10:39:00] >> 49582 [end run-tests 2009.07.26 10:39:00] >> 49583 *** TESTS FAILED >> >> >> - Jay From jay.krell at cornell.edu Sun Jul 26 20:29:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:29:57 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: I can try that. It is a null pointer though I believe. interesting..?? On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, showthread all fail to come up. showheap comes up but doesn't show anything. I've tried some of these in the past and they worked better, though I didn't use them for anything. Maybe just a slow machine? And I'm too impatient? Yes, but I don't think that's the problem. xterm comes right up. As does the empty showheap window. Could be a wierd X server too, granted (Xming). I can try Cygwin/X and I was thinking of buying a commercial one (just for this few minutes of testing per month..) If I don't set DISPLAY ..most still hang, except showthread. Specifically showthread fails, but the others still seem to hang. $ unset DISPLAY $ ./showthread *** *** runtime error: *** Exception "TrestleComm.Failure" not in RAISES list *** file "../src/vbt/TrestleClass.m3", line 33 *** Abort trap (core dumped) I'm not sure that's how it should fail, but failure is expected. I think I've seen the failure mode vary too, but again, failure is expected there. So like we aren't even getting to XOpenDisplay. Hey, not much to debug.. perhaps.. Here is Cube hung. Again this is OpenBSD, not the most mature platform from the Modula-3 point of view. Though imho the platforms are all highly similar. $ gdb ./Cube GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.5"... (gdb) run Starting program: /home/jay/cm3/bin/Cube ? Program received signal SIGINT, Interrupt. -- I hit control-c --- 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) info threads 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched (scp=Cannot access memory at address 0x37b3 ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 (gdb) thread 5 bt A syntax error in expression, near `bt'. (gdb) thread 5 apply bt A syntax error in expression, near `apply bt'. (gdb) thread apply 5 bt Thread 5 (process 3778, thread 0x84901400): #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 Cannot access memory at address 0x37ab #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 4 bt Thread 4 (process 3778, thread 0x84901000): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x849010b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, mutex=0x8afb09e0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) at ../src/vbt/VBTRep.m3:439 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591380) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 3 bt Thread 3 (process 3778, thread 0x8182e800): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182e8b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, mutex=0x20e900dc, abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431 #3 0x00e955a7 in _thread_gc (arg=0x0) at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 #4 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #5 0x0000002b in ?? () #6 0x00000000 in ?? () #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 2 bt Thread 2 (process 3778, thread 0x8182ec00): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182ecb0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, mutex=0x8afb0a50) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) at ../src/vtext/VTView.m3:111 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591980) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 1 bt Thread 1 (process 3778, thread 0x8182e400): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x8182e4b0, fname=0x1 , lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, mutex=0x8afb0b20) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) at ../src/lego/FileBrowserVBT.m3:241 #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591500) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x00e9537f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () ---Type to continue, or q to quit--- #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 (gdb) thread apply 0 bt warning: Unknown thread 0. (gdb) I should debug this more but not now. And we should be sure to try these on other platforms, see if the hangs occur. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 13:57:07 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Stack overflow? > > And yes, I have seen deep recursions like that. What happens if you > use a deeper stack? > > Sent from my iPhone > > On Jul 26, 2009, at 8:48 AM, Jay K wrote: > >> >> Ok here is the formsedit crash. >> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >> PPC_LINUX. >> I can try those again. >> >> >> It doesn't happen every time, but some large fraction, like maybe >> half. >> I changed the SIGsEGV to an assertion failure. >> >> >> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >> -bash-3.00$ ./formsedit >> >> *** >> *** runtime error: >> *** failed. >> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >> *** >> Abort (core dumped) >> >> You can't debug it live because you keep getting interrupted by sig >> usr2. >> >> -bash-3.00$ dbx formsedit core >> >> t at 1 (l at 1) terminated by signal KILL (Killed) >> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >> 0xfe3c00a4 >> >> These statements from the debugger about main/AddUnit don't make >> sense to me. >> >> Current function is main >> 13 RTLinker__AddUnit (FormsEdit_M3); >> >> (dbx) where >> current thread: t at 1 >> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 >> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xfe4680b8 >> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >> 0xfe467ca0 >> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >> 0xfefa5adc >> >> Does the code really recurse like this? >> >> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >> 0xffbf9ca0, 0xfe4a5d >> 00, 0xfef48180), at 0xfef48520 >> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >> 0xff000000, 0x0, 0x0 >> ), at 0xff046ea4 >> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >> 0xffbf9e48, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >> 0xffbf9f18, 0 >> x0, 0xff0437d8), at 0xff043864 >> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >> 0xffbfa0a8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >> 0xffbfa238, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >> 0xffbfa3c8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >> 0xffbfa558, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >> 0xffbfa6e8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >> 0xffbfa878, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >> 0xffbfaa08, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >> 0xffbfab98, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >> 0xffbfad28, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >> 0xffbfaeb8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >> 0xffbfb048, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >> 0xffbfb1d8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >> 0xffbfb368, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >> 0xffbfb4f8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >> 0xffbfb688, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >> 0xffbfb818, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >> 0xffbfb9a8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >> 0xffbfbb38, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >> 0xffbfbcc8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >> 0xffbfbe58, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >> 0xffbfbfe8, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >> 0xffbfc178, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >> 0xffbfc308, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >> 0x0, 0x0), >> at 0xff046ea4 >> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >> 0xffbfc498, >> 0x0, 0xfefbcf58), at 0xfefbcf84 >> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >> 0xfe1b2000, 0x6b170 >> , 0x0), at 0xff046ea4 >> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >> 0xff000000, >> 0x0, 0x0), at 0xff191d20 >> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b27 >> 0, 0x0), at 0xfefb6a38 >> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >> 0xfe1b2000, >> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b290, 0x0), at 0xfefbc9f4 >> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b2b >> 0, 0x0), at 0xfefb6a38 >> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >> 0xfe1b2000, >> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b2d0, 0x0), at 0xfefbc9f4 >> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6af7 >> 0, 0x0), at 0xfefb6a38 >> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >> 0xff000000, >> 0x0, 0x0), at 0xfefbc9f4 >> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b33 >> 0, 0x0), at 0xfefb6a38 >> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b698, 0x0), at 0xfefbc9f4 >> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >> 0xfe1b2000, 0x6b69 >> 8, 0x0), at 0xfefbc9f4 >> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >> 0xfe1b2000, 0xf >> e4a5d00, 0x0), at 0xfefeb348 >> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b6b8, 0x0), at 0xfefbc9f4 >> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >> 0xff000000, 0x0, 0x >> 0), at 0xff157730 >> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b7f >> 8, 0x0), at 0xfefb6a38 >> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b858, 0x0), at 0xfefbc9f4 >> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >> 0x0, 0x0), at >> 0xfefb6a38 >> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b858, 0x0), at 0xfefbc9f4 >> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >> 0xff000000, 0x0 >> , 0x0), at 0xff18d2ec >> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >> 0xfe1b2000, 0x6b87 >> 8, 0x0), at 0xfefb6a38 >> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b898, 0x0), at 0xfefbc9f4 >> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >> 0xfe1b2000, 0x6b89 >> 8, 0x0), at 0xfefbc9f4 >> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >> 0xfe1b2000, 0x6 >> b8b8, 0x0), at 0xfefeb348 >> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >> 0x20, 0xffbfd >> b20), at 0xfefb6a38 >> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >> 0xfe1b2000, >> 0x6b8b8, 0x0), at 0xfefbc9f4 >> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xff01f884 >> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x6b8d8, 0x0), at 0xfefbc9f4 >> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4 >> a5d00, 0x0), at 0xff19e338 >> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >> 0xfe1b2000, >> 0x60338, 0x0), at 0xfefbc9f4 >> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >> 0xfe1b2000, 0xfe4a5d >> 00, 0x0), at 0xfeff6db4 >> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >> 0xff000000, 0x0, 0 >> x0), at 0xfefb6a38 >> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >> 0xfe1b2000 >> , 0x6e5a0, 0x0), at 0xfefbc9f4 >> (dbx) >> (dbx) threads >>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >> ___nanosleep >> () >> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >> in __lwp_pa >> rk() >> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >> ___nanosleep >> () >> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >> in __lwp_pa >> rk() >> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >> in __lwp_pa >> rk() >> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >> in __lwp_pa >> rk() >> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >> __lwp_kill( >> ) >> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >> in __lwp_pa >> rk() >> (dbx) >> >> >> The crashing thread: >> >> (dbx) thread t at 27 >> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >> 0xfe3c11f4 >> (dbx) where >> current thread: t at 27 >> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >> 0xfe35fdd8 >> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >> 0xfe33fff8 >> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >> 0xfe46255c >> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >> 0xfe4529c8 >> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >> 0xfddf0900), at 0x >> fe44f2e4 >> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >> 0xfe4b4d90, 0xff2 >> 50434), at 0xfe44ee5c >> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >> 0x100000), >> at 0xfe44fa0c >> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >> ), >> at 0xfe44f590 >> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >> 0xfffffff8, 0x0, >> 0xfdc53131), at 0xfe44f44c >> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >> 0x0), at 0xfe46 >> 470c >> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >> ), >> at 0xfe44f680 >> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >> 0xfffffff8, 0x0, >> 0xfdc53661), at 0xfe44f44c >> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >> 0x0, 0xfdc538 >> e1), at 0xfe46470c >> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >> 0xfdc53a40, 0xfdc539 >> 2c, 0xfdc53928), at 0xfe42ffe0 >> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >> 0xfdc53a40), a >> t 0xff141d64 >> >> (too many frames for an assertion failure imho!) >> >> >> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >> 0x1000, 0x0, >> 0x0), at 0xff13dda4 >> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >> 0xff000000, 0x0, >> 0x0), at 0xff13d9e8 >> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >> 0xfddf0800, >> 0x69da0, 0x0), at 0xff140730 >> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >> 0xff000000, 0xff00000 >> 0, 0x0, 0x1), at 0xff1407d0 >> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >> 0xfdd221bc), a >> t 0xfefb8f04 >> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >> 0xfefc5170 >> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >> 0xfddf0800, 0x90 >> 410, 0x0), at 0xfefc45a8 >> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >> 0xfefc4674 >> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >> 0xfe46bc00 >> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >> 0xfe46b740, 0x1) >> , at 0xfe46b790 >> (dbx) >> >> >> - Jay From hosking at cs.purdue.edu Sun Jul 26 20:34:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:34:02 -0400 Subject: [M3devel] libz in Tinderbox? In-Reply-To: References: Message-ID: Looks like we have it in /opt/csw/lib/ Sent from my iPhone On Jul 26, 2009, at 1:16 PM, Jay K wrote: > > Tony can you install libz? Or should we import it? Or should we > maybe probe for $HOME/lib/libz.a or somewhere else? > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248619142.5269#err19 > > "/scratch/hosking/work/cm3-ws/niagara-2009-07-26-10-30-05/cm3/m3- > tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake > runtime error: file libz.a not found in /usr/lib /usr/local/lib / > lib /usr/contrib/lib /opt/lib > 22072 > > > There is also: > > Must be attached to terminal for ?am I? option > 49575 + [ niagara = birch.elegosoft.com -a = m3 ] > 49576 ./tinderbox-build.sh: test: argument expected > 49577 r4=1 > 49578 + expr 0 + 0 + 255 + 255 + 1 > 49579 + return 511 > 49580 + date +%Y.%m.%d %H:%M:%S > 49581 + echo [end run-tests 2009.07.26 10:39:00] > 49582 [end run-tests 2009.07.26 10:39:00] > 49583 *** TESTS FAILED > > > - Jay From hosking at cs.purdue.edu Sun Jul 26 20:40:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Jul 2009 14:40:57 -0400 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> Message-ID: <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> Why are we building the X client libs? Xcode should install them? Sent from my iPhone On Jul 26, 2009, at 1:57 PM, Jay K wrote: > From jay.krell at cornell.edu Sun Jul 26 20:46:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 18:46:04 +0000 Subject: [M3devel] Tinderbox/Hudson In-Reply-To: <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> References: <20090726111749.y1gbybgpq84wsgw8@mail.elegosoft.com> <93D6ADD8-562A-40DF-9363-D1FE6A0E8AA8@cs.purdue.edu> <0DCB917C-0DD0-4A24-A91D-7BC7F612C678@cs.purdue.edu> Message-ID: This is just me trying to get my x86 Darwin 10.4 system able to build the Modula-3 gui stuff. Not MacOSX, but Darwin. I don't believe you can do anything at with Xcode on this. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 26 Jul 2009 14:40:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Tinderbox/Hudson > > Why are we building the X client libs? > Xcode should install them? > > Sent from my iPhone > > On Jul 26, 2009, at 1:57 PM, Jay K wrote: > >> From jay.krell at cornell.edu Sun Jul 26 22:43:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Jul 2009 20:43:03 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: Larger stack didn't seem to help. I used export STACKSIZE=32768 and ulimit shownew/showthread come up ok on this platform, OpenBSD/x86 doesn't represent all of them. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] the formsedit crash > Date: Sun, 26 Jul 2009 18:29:57 +0000 > > > I can try that. > > > It is a null pointer though I believe. > > > interesting..?? > > > On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, showthread all fail to come up. > showheap comes up but doesn't show anything. > I've tried some of these in the past and they worked better, though I didn't use them for anything. > > > Maybe just a slow machine? > And I'm too impatient? Yes, but I don't think that's the problem. > > > xterm comes right up. > As does the empty showheap window. > > > Could be a wierd X server too, granted (Xming). > I can try Cygwin/X and I was thinking of buying a commercial one (just for > this few minutes of testing per month..) > > > If I don't set DISPLAY ..most still hang, except showthread. > Specifically showthread fails, but the others still seem to hang. > > > $ unset DISPLAY > $ ./showthread > > *** > *** runtime error: > *** Exception "TrestleComm.Failure" not in RAISES list > *** file "../src/vbt/TrestleClass.m3", line 33 > *** > Abort trap (core dumped) > > > I'm not sure that's how it should fail, but failure is expected. > I think I've seen the failure mode vary too, but again, failure is expected there. > > > So like we aren't even getting to XOpenDisplay. > Hey, not much to debug.. perhaps.. > > > Here is Cube hung. > Again this is OpenBSD, not the most mature platform from the Modula-3 point of view. > Though imho the platforms are all highly similar. > > > $ gdb ./Cube > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) run > Starting program: /home/jay/cm3/bin/Cube > ? > Program received signal SIGINT, Interrupt. -- I hit control-c --- > 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) info threads > 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched (scp=Cannot > access memory at address 0x37b3 > ) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 > 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > (gdb) thread 5 bt > A syntax error in expression, near `bt'. > (gdb) thread 5 apply bt > A syntax error in expression, near `apply bt'. > (gdb) thread apply 5 bt > Thread 5 (process 3778, thread 0x84901400): > #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 > ) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 > Cannot access memory at address 0x37ab > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 4 bt > Thread 4 (process 3778, thread 0x84901000): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x849010b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, mutex=0x8afb09e0) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, > M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, > M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) > at ../src/vbt/VBTRep.m3:439 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591380) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 3 bt > Thread 3 (process 3778, thread 0x8182e800): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182e8b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, mutex=0x20e900dc, > abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431 > #3 0x00e955a7 in _thread_gc (arg=0x0) > at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 > #4 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #5 0x0000002b in ?? () > #6 0x00000000 in ?? () > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 2 bt > Thread 2 (process 3778, thread 0x8182ec00): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182ecb0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, mutex=0x8afb0a50) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, > M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, > M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) > at ../src/vtext/VTView.m3:111 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591980) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 1 bt > Thread 1 (process 3778, thread 0x8182e400): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x8182e4b0, fname=0x1 , lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, mutex=0x8afb0b20) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, > M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, > M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) > at ../src/lego/FileBrowserVBT.m3:241 > #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x07cdc1ca in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x7c591500) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x00e9537f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 > (gdb) thread apply 0 bt > warning: Unknown thread 0. > (gdb) > > I should debug this more but not now. > And we should be sure to try these on other platforms, see if the hangs occur. > > - Jay > > > > > > > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 26 Jul 2009 13:57:07 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> Stack overflow? >> >> And yes, I have seen deep recursions like that. What happens if you >> use a deeper stack? >> >> Sent from my iPhone >> >> On Jul 26, 2009, at 8:48 AM, Jay K wrote: >> >>> >>> Ok here is the formsedit crash. >>> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >>> PPC_LINUX. >>> I can try those again. >>> >>> >>> It doesn't happen every time, but some large fraction, like maybe >>> half. >>> I changed the SIGsEGV to an assertion failure. >>> >>> >>> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >>> -bash-3.00$ ./formsedit >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >>> *** >>> Abort (core dumped) >>> >>> You can't debug it live because you keep getting interrupted by sig >>> usr2. >>> >>> -bash-3.00$ dbx formsedit core >>> >>> t at 1 (l at 1) terminated by signal KILL (Killed) >>> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >>> 0xfe3c00a4 >>> >>> These statements from the debugger about main/AddUnit don't make >>> sense to me. >>> >>> Current function is main >>> 13 RTLinker__AddUnit (FormsEdit_M3); >>> >>> (dbx) where >>> current thread: t at 1 >>> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >>> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at 0xfe3b85e4 >>> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xfe4680b8 >>> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>> 0xfe467ca0 >>> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>> 0xfefa5adc >>> >>> Does the code really recurse like this? >>> >>> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >>> 0xffbf9ca0, 0xfe4a5d >>> 00, 0xfef48180), at 0xfef48520 >>> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >>> 0xff000000, 0x0, 0x0 >>> ), at 0xff046ea4 >>> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >>> 0xffbf9e48, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >>> 0xffbf9f18, 0 >>> x0, 0xff0437d8), at 0xff043864 >>> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >>> 0xffbfa0a8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >>> 0xffbfa238, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >>> 0xffbfa3c8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >>> 0xffbfa558, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >>> 0xffbfa6e8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >>> 0xffbfa878, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >>> 0xffbfaa08, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >>> 0xffbfab98, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >>> 0xffbfad28, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >>> 0xffbfaeb8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >>> 0xffbfb048, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >>> 0xffbfb1d8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >>> 0xffbfb368, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >>> 0xffbfb4f8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >>> 0xffbfb688, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >>> 0xffbfb818, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >>> 0xffbfb9a8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >>> 0xffbfbb38, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >>> 0xffbfbcc8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >>> 0xffbfbe58, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >>> 0xffbfbfe8, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >>> 0xffbfc178, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >>> 0xffbfc308, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >>> 0x0, 0x0), >>> at 0xff046ea4 >>> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >>> 0xffbfc498, >>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >>> 0xfe1b2000, 0x6b170 >>> , 0x0), at 0xff046ea4 >>> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >>> 0xff000000, >>> 0x0, 0x0), at 0xff191d20 >>> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b27 >>> 0, 0x0), at 0xfefb6a38 >>> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b290, 0x0), at 0xfefbc9f4 >>> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b2b >>> 0, 0x0), at 0xfefb6a38 >>> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b2d0, 0x0), at 0xfefbc9f4 >>> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6af7 >>> 0, 0x0), at 0xfefb6a38 >>> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >>> 0xff000000, >>> 0x0, 0x0), at 0xfefbc9f4 >>> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b33 >>> 0, 0x0), at 0xfefb6a38 >>> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b698, 0x0), at 0xfefbc9f4 >>> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >>> 0xfe1b2000, 0x6b69 >>> 8, 0x0), at 0xfefbc9f4 >>> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >>> 0xfe1b2000, 0xf >>> e4a5d00, 0x0), at 0xfefeb348 >>> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b6b8, 0x0), at 0xfefbc9f4 >>> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >>> 0xff000000, 0x0, 0x >>> 0), at 0xff157730 >>> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b7f >>> 8, 0x0), at 0xfefb6a38 >>> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b858, 0x0), at 0xfefbc9f4 >>> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >>> 0x0, 0x0), at >>> 0xfefb6a38 >>> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b858, 0x0), at 0xfefbc9f4 >>> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >>> 0xff000000, 0x0 >>> , 0x0), at 0xff18d2ec >>> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6b87 >>> 8, 0x0), at 0xfefb6a38 >>> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b898, 0x0), at 0xfefbc9f4 >>> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >>> 0xfe1b2000, 0x6b89 >>> 8, 0x0), at 0xfefbc9f4 >>> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >>> 0xfe1b2000, 0x6 >>> b8b8, 0x0), at 0xfefeb348 >>> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >>> 0x20, 0xffbfd >>> b20), at 0xfefb6a38 >>> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >>> 0xfe1b2000, >>> 0x6b8b8, 0x0), at 0xfefbc9f4 >>> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xff01f884 >>> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x6b8d8, 0x0), at 0xfefbc9f4 >>> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4 >>> a5d00, 0x0), at 0xff19e338 >>> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>> 0xfe1b2000, >>> 0x60338, 0x0), at 0xfefbc9f4 >>> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>> 0xfe1b2000, 0xfe4a5d >>> 00, 0x0), at 0xfeff6db4 >>> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >>> 0xff000000, 0x0, 0 >>> x0), at 0xfefb6a38 >>> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >>> 0xfe1b2000 >>> , 0x6e5a0, 0x0), at 0xfefbc9f4 >>> (dbx) >>> (dbx) threads >>>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >>> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >>> ___nanosleep >>> () >>> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >>> in __lwp_pa >>> rk() >>> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >>> ___nanosleep >>> () >>> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >>> in __lwp_pa >>> rk() >>> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >>> in __lwp_pa >>> rk() >>> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >>> in __lwp_pa >>> rk() >>> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >>> __lwp_kill( >>> ) >>> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >>> in __lwp_pa >>> rk() >>> (dbx) >>> >>> >>> The crashing thread: >>> >>> (dbx) thread t at 27 >>> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >>> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >>> 0xfe3c11f4 >>> (dbx) where >>> current thread: t at 27 >>> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >>> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >>> 0xfe35fdd8 >>> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >>> 0xfe33fff8 >>> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >>> 0xfe46255c >>> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >>> 0xfe4529c8 >>> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >>> 0xfddf0900), at 0x >>> fe44f2e4 >>> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >>> 0xfe4b4d90, 0xff2 >>> 50434), at 0xfe44ee5c >>> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >>> 0x100000), >>> at 0xfe44fa0c >>> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >>> ), >>> at 0xfe44f590 >>> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>> 0xfffffff8, 0x0, >>> 0xfdc53131), at 0xfe44f44c >>> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >>> 0x0), at 0xfe46 >>> 470c >>> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, 0x12345678 >>> ), >>> at 0xfe44f680 >>> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>> 0xfffffff8, 0x0, >>> 0xfdc53661), at 0xfe44f44c >>> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >>> 0x0, 0xfdc538 >>> e1), at 0xfe46470c >>> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >>> 0xfdc53a40, 0xfdc539 >>> 2c, 0xfdc53928), at 0xfe42ffe0 >>> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >>> 0xfdc53a40), a >>> t 0xff141d64 >>> >>> (too many frames for an assertion failure imho!) >>> >>> >>> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >>> 0x1000, 0x0, >>> 0x0), at 0xff13dda4 >>> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >>> 0xff000000, 0x0, >>> 0x0), at 0xff13d9e8 >>> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >>> 0xfddf0800, >>> 0x69da0, 0x0), at 0xff140730 >>> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >>> 0xff000000, 0xff00000 >>> 0, 0x0, 0x1), at 0xff1407d0 >>> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >>> 0xfdd221bc), a >>> t 0xfefb8f04 >>> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >>> 0xfefc5170 >>> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >>> 0xfddf0800, 0x90 >>> 410, 0x0), at 0xfefc45a8 >>> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >>> 0xfefc4674 >>> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >>> 0xfe46bc00 >>> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >>> 0xfe46b740, 0x1) >>> , at 0xfe46b790 >>> (dbx) >>> >>> >>> - Jay From wagner at elegosoft.com Sun Jul 26 23:09:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 26 Jul 2009 23:09:45 +0200 Subject: [M3devel] Late news Message-ID: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> Hi again, I just browsed through the latest messages... I can barely keep up with reading everything. Tinderbox results look much better now, almost nothing is red any more. Can you make sure that you're building the branch during release engineering and not from the trunk? I think you are, if you are using the latest defs.sh and not a customized one. Solaris seems to be OK again, after the confusion of yesterday evening. I was not really aware that Tinderbox depends on a GNU date option though. We should add I386_DARWIN to the list of required platform, too, as Tony mentioned. Thanks that you're looking into the formsedit crash now. I guess I was getting a bit impatient this morning :-/ I shouldn't have taken over release engineering if I am though :-) As for setting up Hudson for release engineering: if anyone gives me remote ssh access with a separate account (preferably hudson), enough disk space and CPU power (and JDK >= 1.5), I can set up a slave server for birch remotely without any problems. I've done that several times now. It's just an offer for those who may have idling machines standing in the attic though ;-) I assume it should even work on Windows. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 00:22:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 00:22:58 +0200 Subject: [M3devel] gcc error on PPC_DARWIN Message-ID: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> compiler bootstrap on PPC_DARWIN failed with `invalid option 32': http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console Do we really require 64-bit capable tools now on all systems? Or did I make some stupid error again? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 06:09:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 04:09:02 +0000 Subject: [M3devel] gcc error on PPC_DARWIN In-Reply-To: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> References: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> Message-ID: I kind of throw in that everywhere until/unless shown that it hurts and isn't needed. Indeed it doesn't always work, not always on gcc, not always on cm3cg. I have this probe in Darwin.common now, since I was using an AMD64_DARWIN machine the other day: if not defined("SYSTEM_CC") not this part if equal(WORD_SIZE, "32BITS") SYSTEM_CC = "32" else SYSTEM_CC = "64" end % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -fPIC -m" & SYSTEM_CC local a = SYSTEM_CC & " -arch " & GccArch this part, with -arch or not local b = try_exec("@" & a & " -v 2>/dev/null") if equal(b, 0) SYSTEM_CC = a end %write("SYSTEM_CC is " & SYSTEM_CC & "\n") end if not defined("SYSTEM_LIBTOOL") readonly SYSTEM_LIBTOOL = "libtool" end which should be redundant with the -m32/64 stuff, so try just: if not defined("SYSTEM_CC") % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -fPIC" local a = SYSTEM_CC & " -arch " & GccArch local b = try_exec("@" & a & " -v 2>/dev/null") if equal(b, 0) SYSTEM_CC = a end %write("SYSTEM_CC is " & SYSTEM_CC & "\n") end if not defined("SYSTEM_LIBTOOL") readonly SYSTEM_LIBTOOL = "libtool" end I know this kind of probing is inefficient -- we do it every invocation of cm3. We could at least limit it to if there is a need to compile C or link -- like how GetM3BackFlags works now (sort of -- not probe related, but just related to bootstrapping or not). The alternative is to let users edit or have cminstall do the probe -- and have it go stale when the tools change.. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 00:22:58 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] gcc error on PPC_DARWIN > > compiler bootstrap on PPC_DARWIN failed with `invalid option 32': > http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console > > Do we really require 64-bit capable tools now on all systems? > Or did I make some stupid error again? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 06:16:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 04:16:15 +0000 Subject: [M3devel] crash in m3bundle on SPARC64_OPENBSD Message-ID: == package /dev2/cm3/m3-sys/cm3ide == +++ /cm3/bin/cm3 -build -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSI ON_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in SPARC64_OPENBSD --- ignoring ../src/m3overrides /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x134afc = NoteStackLocations + 0x2c in ../src/runtime/common/RTColl ector.m3 *** Abort trap (core dumped) new source -> compiling Buf.i3 $ cd /dev2/cm3/m3-sys/cm3ide $ rm -rf SPARC64_OPENBSD/ $ /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x134afc = NoteStackLocations + 0x2c in ../src/runtime/common/RTColl ector.m3 *** Abort trap (core dumped) $ gdb --args /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-openbsd4.3"... (gdb) run Starting program: /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk Program received signal SIGSEGV, Segmentation fault. 0x0000000000134afc in RTCollector__NoteStackLocations ( M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) at ../src/runtime/common/RTCollector.m3:525 525 WITH page = AddressToPage(fp^) DO (gdb) disas Dump of assembler code for function RTCollector__NoteStackLocations: 0x0000000000134ad0 : save %sp, -224, %sp 0x0000000000134ad4 : stx %i0, [ %fp + 0x87f ] 0x0000000000134ad8 : stx %i1, [ %fp + 0x887 ] 0x0000000000134adc : ldx [ %fp + 0x8 7f ], %g1 0x0000000000134ae0 : stx %g1, [ %fp + 0x7df ] 0x0000000000134ae4 : ldx [ %fp + 0x8 87 ], %g1 0x0000000000134ae8 : add %g1, -8, %g 1 0x0000000000134aec : stx %g1, [ %fp + 0x887 ] 0x0000000000134af0 : b %xcc, 0x134ba c 0x0000000000134af4 : nop 0x0000000000134af8 : ldx [ %fp + 0x7 df ], %g1 0x0000000000134afc : ldx [ %g1 ], %g <<< here 1 0x0000000000134b00 : mov %g1, %o0 ---Type to continue, or q to quit---q Quit (gdb) p $g1 $1 = 0 <<< null deref (gdb) bt #0 0x0000000000134afc in RTCollector__NoteStackLocations ( M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) at ../src/runtime/common/RTCollector.m3:525 #1 0x000000000015a44c in ThreadPThread__ProcessMe ( M3_CgoaiZ_me=0xd800000000000000, M3_Ad3xEV_p=0x58daebea047a3667) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #2 0x0000000000159e48 in ThreadF__ProcessStacks ( M3_Ad3xEV_p=0x10000000004d8c29) at ../src/thread/PTHREAD/ThreadPThread.m3:938 #3 0x000000000013680c in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:821 #4 0x0000000000135ee4 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:721 #5 0x0000000000135600 in RTCollector__CollectEnough ( M3_AicXUJ_allocator=56 '8') at ../src/runtime/common/RTCollector.m3:653 #6 0x000000000013986c in RTCollector__LongAlloc ( M3_Cwb5VA_dataSize=11889503016258108627, M3_Cwb5VA_dataAlignment=12754194144713243859, M3_D000bG_pool=0xc300000000000000) at ../src/runtime/common/RTCollector.m3:1438 #7 0x0000000000139644 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=0, M3_Cwb5VA_dataAlignment=0, M3_D000bG_pool=0x0) at ../src/runtime/common/RTCollector.m3:1400 #8 0x0000000000130578 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) ---Type to continue, or q to quit--- at ../src/runtime/common/RTAllocator.m3:222 #9 0x000000000012fc50 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:120 #10 0x0000000000156c8c in ThreadPThread__CreateT (M3_CgoaiZ_act=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:497 #11 0x000000000015bb5c in ThreadF__Init () at ../src/thread/PTHREAD/ThreadPThread.m3:1377 #12 0x000000000014392c in RTLinker__InitRuntime ( M3_AcxOUs_p_argc=7455543629306877523, M3_AJWxb1_p_argv=0x5f5253483d737368, M3_AJWxb1_p_envp=0x5353485f545459, M3_AJWxb1_p_instance=0x3d2f6465762f7474) at ../src/runtime/common/RTLinker.m3:59 #13 0x00000000001028e4 in main (argc=0, argv=0x0, envp=0x0) at _m3main.mc:3 It happens every time. wild guess would be that..SPARC platforms without stack walker don't work? No, SPARC32_LINUX does better. That no SPARC64 platform works? Could be. We'll see in SPARC64_SOLARIS, SPARC64_LINUX /eventually/. I'll try to let this go for now, it being SPARC64_OPENBSD.. This is also two releases behind. $ uname -a OpenBSD jay-sun2.jkhome 4.3 GENERIC#1555 sparc64 current OpenBSD release is 4.5. - Jay From jay.krell at cornell.edu Mon Jul 27 09:12:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 07:12:52 +0000 Subject: [M3devel] Late news In-Reply-To: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> References: <20090726230945.zn1gtajzlwk0gg40@mail.elegosoft.com> Message-ID: As for setting up Hudson for release engineering: if anyone gives meremote ssh access with a separate account (preferably hudson), - Can you checkin text files to configure it? - Do you have the thing setup where it submits reports? Ie: where the master doesn't need access to the slave, or such? - All my machines are behind NAT. I think I could give you access one at a time via forwarding port 22?, and actually, I only have the server running so far on NT and one other machine. I wasn't able to get a public key from ~wagner/.ssh or ~hudson/.ssh on birch, access denied ok..I think I have something, separate mail.. - Jay ---------------------------------------- > Date: Sun, 26 Jul 2009 23:09:45 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Late news > > Hi again, > > I just browsed through the latest messages... I can barely keep up > with reading everything. > > Tinderbox results look much better now, almost nothing is red any more. > Can you make sure that you're building the branch during release > engineering and not from the trunk? I think you are, if you are using > the latest defs.sh and not a customized one. > > Solaris seems to be OK again, after the confusion of yesterday evening. > I was not really aware that Tinderbox depends on a GNU date option > though. > > We should add I386_DARWIN to the list of required platform, too, > as Tony mentioned. > > Thanks that you're looking into the formsedit crash now. > I guess I was getting a bit impatient this morning :-/ > I shouldn't have taken over release engineering if I am though :-) > > As for setting up Hudson for release engineering: if anyone gives me > remote ssh access with a separate account (preferably hudson), > enough disk space and CPU power (and JDK>= 1.5), I can set up a > slave server for birch remotely without any problems. I've done > that several times now. > It's just an offer for those who may have idling machines standing in > the attic though ;-) I assume it should even work on Windows. > > So long, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 11:16:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 09:16:48 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: >>> I've heard cvs is a cpu hog, it's one reason people switch away from >>> it (which I hope we'll do after this release..) > > > I'll have to search, initial searches failed. > > >> Not that I know... it usually sleeps while waiting for file i/o. > > > True. Load average is high on birch, 8. I don't know what this means but I thought it was was supposed to be around 1. Or is 1 times the number of processors? cvs, by me and hudson, often visible taking a lot, judging by top. Tinderbox...is causing too much heat in my apartment. After a few green runs I'll have to see about powering the machines on once a week or something for one run and then power back off. Maybe leave just one running daily or in a loop, like LINUXLIB6. Later maybe move all x86/amd64 machines to virtual machines and inherit power management of host or scheduled power off/on. - Jay From jay.krell at cornell.edu Mon Jul 27 13:28:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 11:28:54 +0000 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) Message-ID: CVS checkout and update of an entire tree seem to be extremely unreliable. It takes a while and often times out. I don't have time to do this right now, I think the cvs update/checkout should go like this: if directory doesn't exist: checkout with -l if directory does exist (it always will now actually, this if can go, except to error if it doesn't exist) cd into it upd -l various hardcoded directories, m3-sys scripts m3-ui m3-libs www doc This list need not be complete and it may contain directories that don't exist. for each directory cvs -z3 upd -dAP that directory notice that after the first one, the directory list will be correct Possibly do it like m3-sys m3-sys/m3cc m3-sys/m3gdb m3-libs m3-libs/m3core m3-libs/libm3 to breakdown some of the larger ones. and then one cvs -z3 upd -dAP at the root check return code of just that line one, if failed, wait five minutes try again, if failed, fail I plan to implement this and I'd /prefer/ to use Python. If nobody else wants it, I'll turn it off by default. Even just leaving the workspace aorund doesn't seem to solve the problem. I'd also be curious about -z1 vs. -z3. I usually use -z3. That's what some documentation recommended. - Jay From wagner at elegosoft.com Mon Jul 27 14:30:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 14:30:39 +0200 Subject: [M3devel] crash in m3bundle on SPARC64_OPENBSD In-Reply-To: References: Message-ID: <20090727143039.fp8eyulhb4ggcgkc@mail.elegosoft.com> Please put the evidence into a trac ticket. Thanks, Olaf Quoting Jay K : > > == package /dev2/cm3/m3-sys/cm3ide == > > +++ /cm3/bin/cm3 -build -DROOT=/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 > -DCM3_VERSI > ON_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in SPARC64_OPENBSD --- > ignoring ../src/m3overrides > /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x134afc = NoteStackLocations + 0x2c in > ../src/runtime/common/RTColl > ector.m3 > *** > Abort trap (core dumped) > new source -> compiling Buf.i3 > > $ cd /dev2/cm3/m3-sys/cm3ide > $ rm -rf SPARC64_OPENBSD/ > $ /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x134afc = NoteStackLocations + 0x2c in > ../src/runtime/common/RTColl > ector.m3 > *** > Abort trap (core dumped) > > $ gdb --args /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc64-unknown-openbsd4.3"... > (gdb) run > Starting program: /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000134afc in RTCollector__NoteStackLocations ( > M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) > at ../src/runtime/common/RTCollector.m3:525 > 525 WITH page = AddressToPage(fp^) DO > (gdb) disas > Dump of assembler code for function RTCollector__NoteStackLocations: > 0x0000000000134ad0 : save %sp, -224, %sp > 0x0000000000134ad4 : stx %i0, [ %fp + 0x87f > ] > 0x0000000000134ad8 : stx %i1, [ %fp + 0x887 > ] > 0x0000000000134adc : ldx [ %fp + 0x8 > 7f ], %g1 > 0x0000000000134ae0 : stx %g1, [ %fp > + 0x7df ] > 0x0000000000134ae4 : ldx [ %fp + 0x8 > 87 ], %g1 > 0x0000000000134ae8 : add %g1, -8, %g > 1 > 0x0000000000134aec : stx %g1, [ %fp > + 0x887 ] > 0x0000000000134af0 : b %xcc, 0x134ba > c > 0x0000000000134af4 : nop > 0x0000000000134af8 : ldx [ %fp + 0x7 > df ], %g1 > 0x0000000000134afc : ldx [ %g1 ], %g <<< here > 1 > 0x0000000000134b00 : mov %g1, %o0 > ---Type to continue, or q to quit---q > Quit > (gdb) p $g1 > $1 = 0 <<< null deref > (gdb) bt > #0 0x0000000000134afc in RTCollector__NoteStackLocations ( > M3_AJWxb1_start=0xfffffffffffcbe, M3_AJWxb1_stop=0x61daebea047a30af) > at ../src/runtime/common/RTCollector.m3:525 > #1 0x000000000015a44c in ThreadPThread__ProcessMe ( > M3_CgoaiZ_me=0xd800000000000000, M3_Ad3xEV_p=0x58daebea047a3667) > at ../src/thread/PTHREAD/ThreadPThread.m3:1014 > #2 0x0000000000159e48 in ThreadF__ProcessStacks ( > M3_Ad3xEV_p=0x10000000004d8c29) > at ../src/thread/PTHREAD/ThreadPThread.m3:938 > #3 0x000000000013680c in RTCollector__CollectSomeInStateZero () > at ../src/runtime/common/RTCollector.m3:821 > #4 0x0000000000135ee4 in RTCollector__CollectSome () > at ../src/runtime/common/RTCollector.m3:721 > #5 0x0000000000135600 in RTCollector__CollectEnough ( > M3_AicXUJ_allocator=56 '8') at ../src/runtime/common/RTCollector.m3:653 > #6 0x000000000013986c in RTCollector__LongAlloc ( > M3_Cwb5VA_dataSize=11889503016258108627, > M3_Cwb5VA_dataAlignment=12754194144713243859, > M3_D000bG_pool=0xc300000000000000) > at ../src/runtime/common/RTCollector.m3:1438 > #7 0x0000000000139644 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=0, > M3_Cwb5VA_dataAlignment=0, M3_D000bG_pool=0x0) > at ../src/runtime/common/RTCollector.m3:1400 > #8 0x0000000000130578 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) > ---Type to continue, or q to quit--- > at ../src/runtime/common/RTAllocator.m3:222 > #9 0x000000000012fc50 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) > at ../src/runtime/common/RTAllocator.m3:120 > #10 0x0000000000156c8c in ThreadPThread__CreateT (M3_CgoaiZ_act=0x0) > at ../src/thread/PTHREAD/ThreadPThread.m3:497 > #11 0x000000000015bb5c in ThreadF__Init () > at ../src/thread/PTHREAD/ThreadPThread.m3:1377 > #12 0x000000000014392c in RTLinker__InitRuntime ( > M3_AcxOUs_p_argc=7455543629306877523, > M3_AJWxb1_p_argv=0x5f5253483d737368, M3_AJWxb1_p_envp=0x5353485f545459, > M3_AJWxb1_p_instance=0x3d2f6465762f7474) > at ../src/runtime/common/RTLinker.m3:59 > #13 0x00000000001028e4 in main (argc=0, argv=0x0, envp=0x0) at _m3main.mc:3 > > > It happens every time. > > > wild guess would be that..SPARC platforms without stack walker don't work? > No, SPARC32_LINUX does better. > > > That no SPARC64 platform works? Could be. > We'll see in SPARC64_SOLARIS, SPARC64_LINUX /eventually/. > > > I'll try to let this go for now, it being SPARC64_OPENBSD.. > > > This is also two releases behind. > > > $ uname -a > OpenBSD jay-sun2.jkhome 4.3 GENERIC#1555 sparc64 > > > current OpenBSD release is 4.5. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 15:19:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 15:19:56 +0200 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> Message-ID: <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> Quoting Jay K : >>>> I've heard cvs is a cpu hog, it's one reason people switch away from >>>> it (which I hope we'll do after this release..) >> >> I'll have to search, initial searches failed. >> >>> Not that I know... it usually sleeps while waiting for file i/o. >> >> True. > > Load average is high on birch, 8. > I don't know what this means but I thought it was was supposed to be > around 1. No. The load average is the average number of processes competing for cpu within the last one/five/fifteen minutes. See http://en.wikipedia.org/wiki/Load_(computing) for details. In general no process will wait for CPU at all if your load average is lower than the number of processors. > Or is 1 times the number of processors? o Linux systems count not only runnable processes as the article in Wikipedia says. o Unix systems in general can handle high loads fairly well. o birch is performing a lot of services: CVS, ssh, ftp, web service, trac, mail backup, etc. So a somewhat higher load is expected. > cvs, by me and hudson, often visible taking a lot, judging by top. I really think the limiting factor are the disks, unless you are using compression and/or encryption (-z, ssh access). But that is not inherent to CVS. You will find that running other SCM systems (like ClearCase, Subversion with HTTPS/Apache access, PVCS/Dimensions, ...) will put much higher demands to your resources than simple CVS. > Tinderbox...is causing too much heat in my apartment. After a few > green runs I'll have to see about powering the machines on once a > week or something for one run and then power back off. That's understandable. > Maybe leave just one running daily or in a loop, like LINUXLIB6. > Later maybe move all x86/amd64 machines to virtual machines and > inherit power management of host or scheduled power off/on. I think we should try to obtain access to a few machines in a large data center. Perhaps we can use the HP Partner Virtualization Program. I'm not sure if we can get access for an open source project or need to make a contract as a company (Elego). We'll investigate that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 15:31:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 15:31:55 +0200 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) Message-ID: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> Quoting Jay K : > CVS checkout and update of an entire tree seem to be extremely unreliable. > It takes a while and often times out. It should not take longer than about 5 minutes, and considering the number of files and amount of data to be transferred, that's quite acceptable. > I don't have time to do this right now, I think the cvs > update/checkout should go like this: > > if directory doesn't exist: > checkout with -l > > if directory does exist (it always will now actually, this if can > go, except to error if it doesn't exist) > cd into it > upd -l various hardcoded directories, m3-sys scripts m3-ui m3-libs www doc > This list need not be complete and it may contain directories > that don't exist. > for each directory cvs -z3 upd -dAP that directory > notice that after the first one, the directory list will be correct > Possibly do it like m3-sys m3-sys/m3cc m3-sys/m3gdb m3-libs > m3-libs/m3core m3-libs/libm3 > to breakdown some of the larger ones. > and then one cvs -z3 upd -dAP at the root > check return code of just that line one, if failed, wait five > minutes try again, if failed, fail > > I plan to implement this and I'd /prefer/ to use Python. > > If nobody else wants it, I'll turn it off by default. > > Even just leaving the workspace aorund doesn't seem to solve the problem. I don't think it's a good idea. If you really want to speed it up and make it more robust, replicate the CM3 repo locally and do checkouts via the file system (much faster without ssh). You may run cvsup in a loop to get all changes quickly. If we really run out of resources on birch, we may need to set up a public r/o copy of the repository for cvs access. > I'd also be curious about -z1 vs. -z3. > I usually use -z3. That's what some documentation recommended. I think it may rather make performance worse as compression needs much CPU on birch, which may not be available under high system loads. Please remember that birch is used for other purposes by Elego than only to serve the CM3 repository. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 15:53:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 13:53:09 +0000 Subject: [M3devel] tinderbox status improvements/diagnosis In-Reply-To: <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> References: <20090720145142.xyryqqjksg4w8g0k@mail.elegosoft.com> <20090727151956.1pmvmi4ibvnokkgk@mail.elegosoft.com> Message-ID: I am using ssh, and just -z1. 5 minutes I don't think so. It takes quite a while..maybe a minute, on a cvs -z3 upd from the root before it transfers any files. But subsequent nearby-in-time runs are faster. Some caching affects but they are surprising -- which cache? How much data is being accessed? I don't know, haven't traced it or anything. Yeah some source control is heavyweight but I think many are not. Git seems to be rapidly gaining in popularity and with that you probably hit "the server" much less. I worry "distributed source control" like Git would make sharing changes too infrequent, maybe worse than the other side too requent. I thought cvsup might be a good solution but haven't tried it yet. Only time/interest for so many new things at a time. I'll check with a friend about hosting my weirdo machines. I see the Mac has good command line control of "scheduled wake". If all my hardware had "scheduled wake" would be easy. I only first saw this feature recently on an SGI. I don't know how common it is. Ultimately an Intel Mac with scheduled sleep/wake, and starting up N virtual machines upon startup, either on a schedule or that each wait an hour, two hours, three hours, etc. before doing anything, should be able to substitute for I figure roughly 15 machines -- (Linux + OpenBSD + FreeBSD + NetBSD + Solaris + NT + Darwin) * (I386 + AMD4) + PPC_DARWIN. I had an Intel Mac but returned it and will get a "bigger" (more diskspace) soon. Heck, just run them all serially in a loop, just one heat spewing machine, should be a good setup. And then gradually try to add even more esoteric systems (Spin?). It kind of feels like cheating but also seems like a good idea. VMware has even automated the installs of some operating systems, very nice. Still that leaves PPC, SPARC, MIPS, IA64, Alpha to run on real hardware (though several of those boast virtualization features, I expect it is much harder to get up and running than the x86 virtualization products..) - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 15:19:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] tinderbox status improvements/diagnosis > > Quoting Jay K : > >>>>> I've heard cvs is a cpu hog, it's one reason people switch away from >>>>> it (which I hope we'll do after this release..) >>> >>> I'll have to search, initial searches failed. >>> >>>> Not that I know... it usually sleeps while waiting for file i/o. >>> >>> True. >> >> Load average is high on birch, 8. >> I don't know what this means but I thought it was was supposed to be >> around 1. > > No. The load average is the average number of processes competing for cpu > within the last one/five/fifteen minutes. See > http://en.wikipedia.org/wiki/Load_(computing) for details. > > In general no process will wait for CPU at all if your load average > is lower than the number of processors. > >> Or is 1 times the number of processors? > > o Linux systems count not only runnable processes as the article > in Wikipedia says. > > o Unix systems in general can handle high loads fairly well. > > o birch is performing a lot of services: CVS, ssh, ftp, web service, > trac, mail backup, etc. So a somewhat higher load is expected. > >> cvs, by me and hudson, often visible taking a lot, judging by top. > > I really think the limiting factor are the disks, unless you are > using compression and/or encryption (-z, ssh access). But that is > not inherent to CVS. > > You will find that running other SCM systems (like ClearCase, > Subversion with HTTPS/Apache access, PVCS/Dimensions, ...) will > put much higher demands to your resources than simple CVS. > >> Tinderbox...is causing too much heat in my apartment. After a few >> green runs I'll have to see about powering the machines on once a >> week or something for one run and then power back off. > > That's understandable. > >> Maybe leave just one running daily or in a loop, like LINUXLIB6. > >> Later maybe move all x86/amd64 machines to virtual machines and >> inherit power management of host or scheduled power off/on. > > I think we should try to obtain access to a few machines in a > large data center. Perhaps we can use the HP Partner Virtualization Program. > I'm not sure if we can get access for an open source project or need > to make a contract as a company (Elego). We'll investigate that. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hosking at cs.purdue.edu Mon Jul 27 15:52:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Jul 2009 09:52:46 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: Not sure if doing it that way works. Current default stack size set in ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try changing it there. On 26 Jul 2009, at 16:43, Jay K wrote: > > Larger stack didn't seem to help. > > I used export STACKSIZE=32768 > and ulimit > > shownew/showthread come up ok on this platform, OpenBSD/x86 doesn't > represent all of them. > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] the formsedit crash >> Date: Sun, 26 Jul 2009 18:29:57 +0000 >> >> >> I can try that. >> >> >> It is a null pointer though I believe. >> >> >> interesting..?? >> >> >> On OpenBSD/x86, June, mentor, Cube, shownew, RehearseCode, >> showthread all fail to come up. >> showheap comes up but doesn't show anything. >> I've tried some of these in the past and they worked better, though >> I didn't use them for anything. >> >> >> Maybe just a slow machine? >> And I'm too impatient? Yes, but I don't think that's the problem. >> >> >> xterm comes right up. >> As does the empty showheap window. >> >> >> Could be a wierd X server too, granted (Xming). >> I can try Cygwin/X and I was thinking of buying a commercial one >> (just for >> this few minutes of testing per month..) >> >> >> If I don't set DISPLAY ..most still hang, except showthread. >> Specifically showthread fails, but the others still seem to hang. >> >> >> $ unset DISPLAY >> $ ./showthread >> >> *** >> *** runtime error: >> *** Exception "TrestleComm.Failure" not in RAISES list >> *** file "../src/vbt/TrestleClass.m3", line 33 >> *** >> Abort trap (core dumped) >> >> >> I'm not sure that's how it should fail, but failure is expected. >> I think I've seen the failure mode vary too, but again, failure is >> expected there. >> >> >> So like we aren't even getting to XOpenDisplay. >> Hey, not much to debug.. perhaps.. >> >> >> Here is Cube hung. >> Again this is OpenBSD, not the most mature platform from the >> Modula-3 point of view. >> Though imho the platforms are all highly similar. >> >> >> $ gdb ./Cube >> GNU gdb 6.3 >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) run >> Starting program: /home/jay/cm3/bin/Cube >> ? >> Program received signal SIGINT, Interrupt. -- I hit control-c --- >> 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) info threads >> 5 process 3778, thread 0x84901400 (SLEEP_WAIT) _thread_kern_sched >> (scp=Cannot >> access memory at address 0x37b3 >> ) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 >> 4 process 3778, thread 0x84901000 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 3 process 3778, thread 0x8182e800 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 2 process 3778, thread 0x8182ec00 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> 1 process 3778, thread 0x8182e400 (COND_WAIT) _thread_kern_sched >> (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> (gdb) thread 5 bt >> A syntax error in expression, near `bt'. >> (gdb) thread 5 apply bt >> A syntax error in expression, near `apply bt'. >> (gdb) thread apply 5 bt >> Thread 5 (process 3778, thread 0x84901400): >> #0 _thread_kern_sched (scp=Cannot access memory at address 0x37b3 >> ) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:392 >> Cannot access memory at address 0x37ab >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 4 bt >> Thread 4 (process 3778, thread 0x84901000): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x849010b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0950, >> mutex=0x8afb09e0) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7586c8, >> M3_AYIbX3_m=0x7c758688, M3_Bl0jv4_c=0x7c758694, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c758688, >> M3_Bl0jv4_c=0x7c758694) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0b2941d4 in VBTRep__MeterMaid (M3_EMTrVz_self=0x7c7586bc) >> at ../src/vbt/VBTRep.m3:439 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591380) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591380) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 3 bt >> Thread 3 (process 3778, thread 0x8182e800): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182e8b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9be2d in pthread_cond_timedwait (cond=0x20e900e0, >> mutex=0x20e900dc, >> abstime=0x89a07fa8) at /usr/src/lib/libpthread/uthread/ >> uthread_cond.c:431 >> #3 0x00e955a7 in _thread_gc (arg=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_gc.c:181 >> #4 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #5 0x0000002b in ?? () >> #6 0x00000000 in ?? () >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 2 bt >> Thread 2 (process 3778, thread 0x8182ec00): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182ecb0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb08c0, >> mutex=0x8afb0a50) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c7610d4, >> M3_AYIbX3_m=0x7c7610b0, M3_Bl0jv4_c=0x7c7610bc, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7610b0, >> M3_Bl0jv4_c=0x7c7610bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0a541a61 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x7c7610cc) >> at ../src/vtext/VTView.m3:111 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591980) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591980) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 1 bt >> Thread 1 (process 3778, thread 0x8182e400): >> #0 _thread_kern_sched (scp=0x0) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 >> #1 0x00e9e200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, >> lock=0x8182e4b0, fname=0x1 , lineno=1) >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 >> #2 0x00e9bbc9 in pthread_cond_wait (cond=0x8afb0b00, >> mutex=0x8afb0b20) >> at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 >> #3 0x07cda32d in ThreadPThread__XWait (M3_BXP32l_self=0x7c763a08, >> M3_AYIbX3_m=0x7c7639ac, M3_Bl0jv4_c=0x7c7639b8, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:227 >> #4 0x07cda9d9 in Thread__Wait (M3_AYIbX3_m=0x7c7639ac, >> M3_Bl0jv4_c=0x7c7639b8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x0a4bc35b in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x7c763a00) >> at ../src/lego/FileBrowserVBT.m3:241 >> #6 0x07cdc49f in ThreadPThread__RunThread (M3_BeUkBA_me=0x7c591500) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x07cdc1ca in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x7c591500) >> at ../src/thread/PTHREAD/ThreadPThread.m3:523 >> #8 0x00e9537f in _thread_start () >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240 >> #9 0x0000002b in ?? () >> #10 0x00000000 in ?? () >> ---Type to continue, or q to quit--- >> #0 0x02e2e8f1 in poll () from /usr/lib/libc.so.50.1 >> (gdb) thread apply 0 bt >> warning: Unknown thread 0. >> (gdb) >> >> I should debug this more but not now. >> And we should be sure to try these on other platforms, see if the >> hangs occur. >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 26 Jul 2009 13:57:07 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] the formsedit crash >>> >>> Stack overflow? >>> >>> And yes, I have seen deep recursions like that. What happens if you >>> use a deeper stack? >>> >>> Sent from my iPhone >>> >>> On Jul 26, 2009, at 8:48 AM, Jay K wrote: >>> >>>> >>>> Ok here is the formsedit crash. >>>> This is on SOLgnu. I have also seen it on either PPC_DARWIN or >>>> PPC_LINUX. >>>> I can try those again. >>>> >>>> >>>> It doesn't happen every time, but some large fraction, like maybe >>>> half. >>>> I changed the SIGsEGV to an assertion failure. >>>> >>>> >>>> -bash-3.00$ export DISPLAY=192.168.1.120:0.0 >>>> -bash-3.00$ ./formsedit >>>> >>>> *** >>>> *** runtime error: >>>> *** failed. >>>> *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 >>>> *** >>>> Abort (core dumped) >>>> >>>> You can't debug it live because you keep getting interrupted by sig >>>> usr2. >>>> >>>> -bash-3.00$ dbx formsedit core >>>> >>>> t at 1 (l at 1) terminated by signal KILL (Killed) >>>> 0xfe3c0094: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! >>>> 0xfe3c00a4 >>>> >>>> These statements from the debugger about main/AddUnit don't make >>>> sense to me. >>>> >>>> Current function is main >>>> 13 RTLinker__AddUnit (FormsEdit_M3); >>>> >>>> (dbx) where >>>> current thread: t at 1 >>>> [1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xfde1e000, 0x1), at 0xfe3c0094 >>>> [2] mutex_lock_queue(0x0, 0x0, 0x6e978, 0x0, 0x0, 0x1), at >>>> 0xfe3b85e4 >>>> [3] ThreadPThread__LockMutex(0xfdd5902c, 0x1000, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xfe4680b8 >>>> [4] Thread__Acquire(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>>> 0xfe467ca0 >>>> [5] TrestleOnX__Enter(0xfdd5902c, 0x0, 0x0, 0x1000, 0x0, 0x0), at >>>> 0xfefa5adc >>>> >>>> Does the code really recurse like this? >>>> >>>> [6] XClient__ScreenOf(0xfdd5902c, 0xfdd25138, 0xfee9e520, >>>> 0xffbf9ca0, 0xfe4a5d >>>> 00, 0xfef48180), at 0xfef48520 >>>> [7] Trestle__ScreenOf(0xfdd25138, 0xfee9e520, 0xffbf9e48, >>>> 0xff000000, 0x0, 0x0 >>>> ), at 0xff046ea4 >>>> [8] VBTClass__ScreenOfDefault(0xfdd25138, 0xfdea516c, 0xfee9e520, >>>> 0xffbf9e48, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [9] Trestle__IParentScreenOf(0xfdd25138, 0xfdea516c, 0xfee9e520, >>>> 0xffbf9f18, 0 >>>> x0, 0xff0437d8), at 0xff043864 >>>> [10] Trestle__ScreenOf(0xfdea516c, 0xfee9e520, 0xffbfa0a8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [11] VBTClass__ScreenOfDefault(0xfdea516c, 0xfdeaa434, 0xfee9e520, >>>> 0xffbfa0a8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [12] Trestle__ScreenOf(0xfdeaa434, 0xfee9e520, 0xffbfa238, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [13] VBTClass__ScreenOfDefault(0xfdeaa434, 0xfdeaa508, 0xfee9e520, >>>> 0xffbfa238, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [14] Trestle__ScreenOf(0xfdeaa508, 0xfee9e520, 0xffbfa3c8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [15] VBTClass__ScreenOfDefault(0xfdeaa508, 0xfdeaa490, 0xfee9e520, >>>> 0xffbfa3c8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [16] Trestle__ScreenOf(0xfdeaa490, 0xfee9e520, 0xffbfa558, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [17] VBTClass__ScreenOfDefault(0xfdeaa490, 0xfdeb0d3c, 0xfee9e520, >>>> 0xffbfa558, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [18] Trestle__ScreenOf(0xfdeb0d3c, 0xfee9e520, 0xffbfa6e8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [19] VBTClass__ScreenOfDefault(0xfdeb0d3c, 0xfdeccdd0, 0xfee9e520, >>>> 0xffbfa6e8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [20] Trestle__ScreenOf(0xfdeccdd0, 0xfee9e520, 0xffbfa878, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [21] VBTClass__ScreenOfDefault(0xfdeccdd0, 0xfdeccd5c, 0xfee9e520, >>>> 0xffbfa878, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [22] Trestle__ScreenOf(0xfdeccd5c, 0xfee9e520, 0xffbfaa08, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [23] VBTClass__ScreenOfDefault(0xfdeccd5c, 0xfdecccd0, 0xfee9e520, >>>> 0xffbfaa08, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [24] Trestle__ScreenOf(0xfdecccd0, 0xfee9e520, 0xffbfab98, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [25] VBTClass__ScreenOfDefault(0xfdecccd0, 0xfdd5bbfc, 0xfee9e520, >>>> 0xffbfab98, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [26] Trestle__ScreenOf(0xfdd5bbfc, 0xfee9e520, 0xffbfad28, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [27] VBTClass__ScreenOfDefault(0xfdd5bbfc, 0xfddbee18, 0xfee9e520, >>>> 0xffbfad28, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [28] Trestle__ScreenOf(0xfddbee18, 0xfee9e520, 0xffbfaeb8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [29] VBTClass__ScreenOfDefault(0xfddbee18, 0xfdd3bd78, 0xfee9e520, >>>> 0xffbfaeb8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [30] Trestle__ScreenOf(0xfdd3bd78, 0xfee9e520, 0xffbfb048, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [31] VBTClass__ScreenOfDefault(0xfdd3bd78, 0xfdd413f4, 0xfee9e520, >>>> 0xffbfb048, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [32] Trestle__ScreenOf(0xfdd413f4, 0xfee9e520, 0xffbfb1d8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [33] VBTClass__ScreenOfDefault(0xfdd413f4, 0xfdce23bc, 0xfee9e520, >>>> 0xffbfb1d8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [34] Trestle__ScreenOf(0xfdce23bc, 0xfee9e520, 0xffbfb368, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [35] VBTClass__ScreenOfDefault(0xfdce23bc, 0xfdce3094, 0xfee9e520, >>>> 0xffbfb368, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [36] Trestle__ScreenOf(0xfdce3094, 0xfee9e520, 0xffbfb4f8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [37] VBTClass__ScreenOfDefault(0xfdce3094, 0xfdce2430, 0xfee9e520, >>>> 0xffbfb4f8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [38] Trestle__ScreenOf(0xfdce2430, 0xfee9e520, 0xffbfb688, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [39] VBTClass__ScreenOfDefault(0xfdce2430, 0xfdd41468, 0xfee9e520, >>>> 0xffbfb688, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [40] Trestle__ScreenOf(0xfdd41468, 0xfee9e520, 0xffbfb818, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [41] VBTClass__ScreenOfDefault(0xfdd41468, 0xfdcd6f7c, 0xfee9e520, >>>> 0xffbfb818, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [42] Trestle__ScreenOf(0xfdcd6f7c, 0xfee9e520, 0xffbfb9a8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [43] VBTClass__ScreenOfDefault(0xfdcd6f7c, 0xfdcd625c, 0xfee9e520, >>>> 0xffbfb9a8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [44] Trestle__ScreenOf(0xfdcd625c, 0xfee9e520, 0xffbfbb38, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [45] VBTClass__ScreenOfDefault(0xfdcd625c, 0xfdcd528c, 0xfee9e520, >>>> 0xffbfbb38, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [46] Trestle__ScreenOf(0xfdcd528c, 0xfee9e520, 0xffbfbcc8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [47] VBTClass__ScreenOfDefault(0xfdcd528c, 0xfdcd1948, 0xfee9e520, >>>> 0xffbfbcc8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [48] Trestle__ScreenOf(0xfdcd1948, 0xfee9e520, 0xffbfbe58, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [49] VBTClass__ScreenOfDefault(0xfdcd1948, 0xfdcd16dc, 0xfee9e520, >>>> 0xffbfbe58, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [50] Trestle__ScreenOf(0xfdcd16dc, 0xfee9e520, 0xffbfbfe8, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [51] VBTClass__ScreenOfDefault(0xfdcd16dc, 0xfdcd1670, 0xfee9e520, >>>> 0xffbfbfe8, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [52] Trestle__ScreenOf(0xfdcd1670, 0xfee9e520, 0xffbfc178, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [53] VBTClass__ScreenOfDefault(0xfdcd1670, 0xfdcd1750, 0xfee9e520, >>>> 0xffbfc178, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [54] Trestle__ScreenOf(0xfdcd1750, 0xfee9e520, 0xffbfc308, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [55] VBTClass__ScreenOfDefault(0xfdcd1750, 0xfdcd506c, 0xfee9e520, >>>> 0xffbfc308, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [56] Trestle__ScreenOf(0xfdcd506c, 0xfee9e520, 0xffbfc498, 0x1000, >>>> 0x0, 0x0), >>>> at 0xff046ea4 >>>> [57] VBTClass__ScreenOfDefault(0xfdcd506c, 0xfdcd7608, 0xfee9e520, >>>> 0xffbfc498, >>>> 0x0, 0xfefbcf58), at 0xfefbcf84 >>>> [58] Trestle__ScreenOf(0xfdcd7608, 0xfee9e520, 0xffbfc594, >>>> 0xfe1b2000, 0x6b170 >>>> , 0x0), at 0xff046ea4 >>>> [59] TrillSwitchVBT__Rescreen(0xfdcd7608, 0xffbfc630, 0xff000000, >>>> 0xff000000, >>>> 0x0, 0x0), at 0xff191d20 >>>> [60] VBTClass__Rescreen(0xfdcd7608, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b27 >>>> 0, 0x0), at 0xfefb6a38 >>>> [61] VBTClass__RescreenDefault(0xfdcd506c, 0xffbfc790, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>>> [62] VBTClass__Rescreen(0xfdcd506c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [63] VBTClass__RescreenDefault(0xfdcd1750, 0xffbfc968, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b290, 0x0), at 0xfefbc9f4 >>>> [64] FlexVBT__Rescreen(0xfdcd1750, 0xffbfc968, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [65] VBTClass__Rescreen(0xfdcd1750, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b2b >>>> 0, 0x0), at 0xfefb6a38 >>>> [66] VBTClass__RescreenDefault(0xfdcd1670, 0xffbfcac8, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0xfe4a5d00, 0x0), at 0xfefbc9f4 >>>> [67] VBTClass__Rescreen(0xfdcd1670, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [68] VBTClass__RescreenDefault(0xfdcd16dc, 0xffbfcca0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b2d0, 0x0), at 0xfefbc9f4 >>>> [69] FlexVBT__Rescreen(0xfdcd16dc, 0xffbfcca0, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [70] VBTClass__Rescreen(0xfdcd16dc, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6af7 >>>> 0, 0x0), at 0xfefb6a38 >>>> [71] VBTClass__RescreenDefault(0xfdcd1948, 0xffbfce00, 0xff000000, >>>> 0xff000000, >>>> 0x0, 0x0), at 0xfefbc9f4 >>>> [72] VBTClass__Rescreen(0xfdcd1948, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b33 >>>> 0, 0x0), at 0xfefb6a38 >>>> [73] VBTClass__RescreenDefault(0xfdcd528c, 0xffbfcf60, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b698, 0x0), at 0xfefbc9f4 >>>> [74] VBTClass__Rescreen(0xfdcd528c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [75] VBTClass__RescreenDefault(0xfdcd625c, 0xffbfd158, 0x1, >>>> 0xfe1b2000, 0x6b69 >>>> 8, 0x0), at 0xfefbc9f4 >>>> [76] BorderedVBT__Rescreen(0xfdcd625c, 0xffbfd158, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xf >>>> e4a5d00, 0x0), at 0xfefeb348 >>>> [77] VBTClass__Rescreen(0xfdcd625c, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [78] VBTClass__RescreenDefault(0xfdcd6f7c, 0xffbfd330, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b6b8, 0x0), at 0xfefbc9f4 >>>> [79] FlexVBT__Rescreen(0xfdcd6f7c, 0xffbfd330, 0xff000000, >>>> 0xff000000, 0x0, 0x >>>> 0), at 0xff157730 >>>> [80] VBTClass__Rescreen(0xfdcd6f7c, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b7f >>>> 8, 0x0), at 0xfefb6a38 >>>> [81] VBTClass__RescreenDefault(0xfdd41468, 0xffbfd490, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b858, 0x0), at 0xfefbc9f4 >>>> [82] VBTClass__Rescreen(0xfdd41468, 0xfdd598c8, 0x1, 0xff000000, >>>> 0x0, 0x0), at >>>> 0xfefb6a38 >>>> [83] VBTClass__RescreenDefault(0xfdce2430, 0xffbfd668, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b858, 0x0), at 0xfefbc9f4 >>>> [84] ShadowedVBT__Rescreen(0xfdce2430, 0xffbfd668, 0xff000000, >>>> 0xff000000, 0x0 >>>> , 0x0), at 0xff18d2ec >>>> [85] VBTClass__Rescreen(0xfdce2430, 0xfdd598c8, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6b87 >>>> 8, 0x0), at 0xfefb6a38 >>>> [86] VBTClass__RescreenDefault(0xfdce3094, 0xffbfd7c8, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b898, 0x0), at 0xfefbc9f4 >>>> [87] VBTClass__Rescreen(0xfdce3094, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [88] VBTClass__RescreenDefault(0xfdce23bc, 0xffbfd9c0, 0x1, >>>> 0xfe1b2000, 0x6b89 >>>> 8, 0x0), at 0xfefbc9f4 >>>> [89] BorderedVBT__Rescreen(0xfdce23bc, 0xffbfd9c0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0x6 >>>> b8b8, 0x0), at 0xfefeb348 >>>> [90] VBTClass__Rescreen(0xfdce23bc, 0xfdd598c8, 0x0, 0xffbfda28, >>>> 0x20, 0xffbfd >>>> b20), at 0xfefb6a38 >>>> [91] VBTClass__RescreenDefault(0xfdd413f4, 0xffbfdbe0, 0xffbfdb20, >>>> 0xfe1b2000, >>>> 0x6b8b8, 0x0), at 0xfefbc9f4 >>>> [92] StableVBT__Rescreen(0xfdd413f4, 0xffbfdbe0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xff01f884 >>>> [93] VBTClass__Rescreen(0xfdd413f4, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [94] VBTClass__RescreenDefault(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x6b8d8, 0x0), at 0xfefbc9f4 >>>> [95] ZChildVBT__Rescreen(0xfdd3bd78, 0xffbfddd0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4 >>>> a5d00, 0x0), at 0xff19e338 >>>> [96] VBTClass__Rescreen(0xfdd3bd78, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [97] VBTClass__RescreenDefault(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>>> 0xfe1b2000, >>>> 0x60338, 0x0), at 0xfefbc9f4 >>>> [98] ZSplit__Rescreen(0xfddbee18, 0xffbfdfd0, 0xfe3ecbc0, >>>> 0xfe1b2000, 0xfe4a5d >>>> 00, 0x0), at 0xfeff6db4 >>>> [99] VBTClass__Rescreen(0xfddbee18, 0xfdd598c8, 0xff000000, >>>> 0xff000000, 0x0, 0 >>>> x0), at 0xfefb6a38 >>>> [100] VBTClass__RescreenDefault(0xfdd5bbfc, 0xffbfe1a8, 0xfe3ecbc0, >>>> 0xfe1b2000 >>>> , 0x6e5a0, 0x0), at 0xfefbc9f4 >>>> (dbx) >>>> (dbx) threads >>>>> t at 1 a l at 1 ?() LWP suspended in __lwp_park() >>>> t at 2 a l at 2 ThreadPThread__ThreadBase() LWP suspended in >>>> ___nanosleep >>>> () >>>> t at 3 a l at 3 ThreadPThread__ThreadBase() sleep on 0x4a1c8 >>>> in __lwp_pa >>>> rk() >>>> t at 4 a l at 4 ThreadPThread__ThreadBase() LWP suspended in >>>> ___nanosleep >>>> () >>>> t at 11 a l at 11 ThreadPThread__ThreadBase() sleep on 0x6e978 >>>> in __lwp_pa >>>> rk() >>>> t at 12 a l at 12 ThreadPThread__ThreadBase() sleep on 0x664a8 >>>> in __lwp_pa >>>> rk() >>>> t at 13 a l at 13 ThreadPThread__ThreadBase() sleep on 0x664c0 >>>> in __lwp_pa >>>> rk() >>>> o t at 27 a l at 27 ThreadPThread__ThreadBase() signal SIGABRT in >>>> __lwp_kill( >>>> ) >>>> t at 28 a l at 28 ThreadPThread__ThreadBase() sleep on 0x600d0 >>>> in __lwp_pa >>>> rk() >>>> (dbx) >>>> >>>> >>>> The crashing thread: >>>> >>>> (dbx) thread t at 27 >>>> t at 27 (l at 27) stopped in __lwp_kill at 0xfe3c11e4 >>>> 0xfe3c11e4: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! >>>> 0xfe3c11f4 >>>> (dbx) where >>>> current thread: t at 27 >>>> =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe3c11e4 >>>> [2] raise(0x6, 0x0, 0xfe3a4af8, 0xffffffff, 0xfe3e8284, 0x6), at >>>> 0xfe35fdd8 >>>> [3] abort(0x70f64, 0x1, 0xfe4705dc, 0xa8390, 0xfe3eb298, 0x0), at >>>> 0xfe33fff8 >>>> [4] RTOS__Crash(0x1, 0x44, 0x48, 0x0, 0xb41a18, 0xb41340), at >>>> 0xfe46255c >>>> [5] RTProcess__Crash(0x0, 0x3, 0xa, 0x1, 0x200000, 0x100000), at >>>> 0xfe4529c8 >>>> [6] RTError__EndError(0x1, 0x0, 0xfe4b4d90, 0x4, 0x180c508, >>>> 0xfddf0900), at 0x >>>> fe44f2e4 >>>> [7] RTError__MsgS(0xff250434, 0x145, 0xfe4b4d90, 0xfe4af4f8, >>>> 0xfe4b4d90, 0xff2 >>>> 50434), at 0xfe44ee5c >>>> [8] RTException__Crash(0xfdc538b4, 0x0, 0xfe4af3a8, 0x1, 0x200000, >>>> 0x100000), >>>> at 0xfe44fa0c >>>> [9] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, >>>> 0x12345678 >>>> ), >>>> at 0xfe44f590 >>>> [10] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>>> 0xfffffff8, 0x0, >>>> 0xfdc53131), at 0xfe44f44c >>>> [11] RTException__Raise(0xfdc538b4, 0xfdc53668, 0x0, 0x0, 0x0, >>>> 0x0), at 0xfe46 >>>> 470c >>>> [12] RTException__DefaultBackstop(0xfdc538b4, 0x0, 0x0, 0x4, 0x0, >>>> 0x12345678 >>>> ), >>>> at 0xfe44f680 >>>> [13] RTException__InvokeBackstop(0xfdc538b4, 0x0, 0xffffffff, >>>> 0xfffffff8, 0x0, >>>> 0xfdc53661), at 0xfe44f44c >>>> [14] RTException__Raise(0xfdc538b4, 0x0, 0xffffffff, 0xfffffff8, >>>> 0x0, 0xfdc538 >>>> e1), at 0xfe46470c >>>> [15] RTHooks__ReportFault(0xff250560, 0x28a0, 0xfdc53a50, >>>> 0xfdc53a40, 0xfdc539 >>>> 2c, 0xfdc53928), at 0xfe42ffe0 >>>> [16] _m3_fault(0x28a0, 0xfee9f4a4, 0xfdd37db4, 0x1, 0xfdc53a50, >>>> 0xfdc53a40), a >>>> t 0xff141d64 >>>> >>>> (too many frames for an assertion failure imho!) >>>> >>>> >>>> [17] ScrollerVBTClass__PaintViewWithShadows(0xfdd3a340, 0x0, 0x0, >>>> 0x1000, 0x0, >>>> 0x0), at 0xff13dda4 >>>> [18] ScrollerVBTClass__PaintView(0xfdd3a340, 0x0, 0xff000000, >>>> 0xff000000, 0x0, >>>> 0x0), at 0xff13d9e8 >>>> [19] ScrollerVBTClass__Repaint(0xfdd3a340, 0xfdc53bdc, 0xfe3ecbc0, >>>> 0xfddf0800, >>>> 0x69da0, 0x0), at 0xff140730 >>>> [20] ScrollerVBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, >>>> 0xff000000, 0xff00000 >>>> 0, 0x0, 0x1), at 0xff1407d0 >>>> [21] VBTClass__Redisplay(0xfdd3a340, 0xfdc53d24, 0x0, 0x4, 0x0, >>>> 0xfdd221bc), a >>>> t 0xfefb8f04 >>>> [22] VBTRep__Redisplay(0xfde974bc, 0x0, 0x0, 0x1000, 0x0, 0x1), at >>>> 0xfefc5170 >>>> [23] VBTRep__UncoverRedisplay(0xfde97318, 0x1000, 0xfe3ecbc0, >>>> 0xfddf0800, 0x90 >>>> 410, 0x0), at 0xfefc45a8 >>>> [24] VBTRep__RdApply(0xfde974c8, 0x0, 0x0, 0x0, 0x0, 0x0), at >>>> 0xfefc4674 >>>> [25] ThreadPThread__RunThread(0x70f30, 0x0, 0x0, 0x0, 0x0, 0x1), at >>>> 0xfe46bc00 >>>> [26] ThreadPThread__ThreadBase(0x70f30, 0xfdc54000, 0x0, 0x0, >>>> 0xfe46b740, 0x1) >>>> , at 0xfe46b790 >>>> (dbx) >>>> >>>> >>>> - Jay From hosking at cs.purdue.edu Mon Jul 27 15:56:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Jul 2009 09:56:44 -0400 Subject: [M3devel] gcc error on PPC_DARWIN In-Reply-To: References: <20090727002258.pswm0d42cc40kkwg@mail.elegosoft.com> Message-ID: <567D958D-EBCE-4358-8D97-80688C544CAD@cs.purdue.edu> -m32 should work. On 27 Jul 2009, at 00:09, Jay K wrote: > > I kind of throw in that everywhere until/unless shown that it hurts > and isn't needed. > Indeed it doesn't always work, not always on gcc, not always on cm3cg. > > > I have this probe in Darwin.common now, since I was using an > AMD64_DARWIN machine the other day: > > > if not defined("SYSTEM_CC") > not this part > if equal(WORD_SIZE, "32BITS") > SYSTEM_CC = "32" > else > SYSTEM_CC = "64" > end > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > SYSTEM_CC = "gcc -fPIC -m" & SYSTEM_CC > local a = SYSTEM_CC & " -arch " & GccArch > this part, with -arch or not > local b = try_exec("@" & a & " -v 2>/dev/null") > if equal(b, 0) > SYSTEM_CC = a > end > %write("SYSTEM_CC is " & SYSTEM_CC & "\n") > end > if not defined("SYSTEM_LIBTOOL") > readonly SYSTEM_LIBTOOL = "libtool" > end > > > which should be redundant with the -m32/64 stuff, so try just: > > > if not defined("SYSTEM_CC") > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > SYSTEM_CC = "gcc -fPIC" > local a = SYSTEM_CC & " -arch " & GccArch > local b = try_exec("@" & a & " -v 2>/dev/null") > if equal(b, 0) > SYSTEM_CC = a > end > %write("SYSTEM_CC is " & SYSTEM_CC & "\n") > end > if not defined("SYSTEM_LIBTOOL") > readonly SYSTEM_LIBTOOL = "libtool" > end > > I know this kind of probing is inefficient -- we do it every > invocation of cm3. > We could at least limit it to if there is a need to compile C or > link -- like how GetM3BackFlags works now (sort of -- not probe > related, but just related to bootstrapping or not). > The alternative is to let users edit or have cminstall do the probe > -- and have it go stale when the tools change.. > > - Jay > > > > > ---------------------------------------- >> Date: Mon, 27 Jul 2009 00:22:58 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] gcc error on PPC_DARWIN >> >> compiler bootstrap on PPC_DARWIN failed with `invalid option 32': >> http://hudson.modula3.com:8080/job/cm3-release-build-PPC_DARWIN/3/console >> >> Do we really require 64-bit capable tools now on all systems? >> Or did I make some stupid error again? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jul 27 16:53:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 16:53:08 +0200 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> Message-ID: <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Quoting Tony Hosking : > Not sure if doing it that way works. Current default stack size set in > ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try > changing it there. There used to be a procedure IncreaseDefaultStackSize. IITR we needed that for several M3 applications on some platforms several years ago. But probably we should also set the default for a target platform so that all our own applications are able to run. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 27 17:24:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 15:24:16 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Message-ID: I don't think this is a stack overflow but I will try that. We should probably drastically increase the defaults. Like make them match whatever the underlying platform uses, or just make sure that unless the user intercedes, that we don't either. The whole notion of a limited size stack is pretty flawed imho. And much worse if you engage in reducing it from the default. How much stack do I need to leave for fopen to work? What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 16:53:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Quoting Tony Hosking : > >> Not sure if doing it that way works. Current default stack size set in >> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >> changing it there. > > There used to be a procedure IncreaseDefaultStackSize. IITR we needed > that for several M3 applications on some platforms several years ago. > > But probably we should also set the default for a target platform > so that all our own applications are able to run. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 27 18:26:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:26:11 +0000 Subject: [M3devel] extra files in workspace Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1248711232.27188 ? cm3/m3-db/db/test/stderr 16 ? cm3/m3-db/odbc/test/stderr 17 ? cm3/m3-db/postgres95/test/stderr 18 ? cm3/m3-db/stable/test/stderr 19 ? cm3/m3-libs/arithmetic/test/stderr 20 ? cm3/m3-libs/binIO/test/PPC_LINUX 21 ? cm3/m3-libs/binIO/test/stderr 22 ? cm3/m3-libs/bitvector/test/stderr 23 ? cm3/m3-libs/libm3/tests/PPC_LINUX 24 ? cm3/m3-libs/libm3/tests/stderr 25 ? cm3/m3-libs/patternmatching/tests/stderr 26 ? cm3/m3-libs/slisp/tests/stderr 27 ? cm3/m3-libs/unittest-numeric/PPC_LINUX 28 ? cm3/m3-sys/cm3/test/PPC_LINUX 29 ? cm3/m3-sys/cm3/test/stderr 30 ? cm3/m3-sys/cm3ide/PPC_LINUX 31 ? cm3/m3-sys/m3cc/tmp-stdout-13571 32 ? cm3/m3-sys/m3quake/test/PPC_LINUX 33 ? cm3/m3-sys/m3quake/test/stderr 34 ? cm3/m3-sys/m3tests/PPC_LINUX 35 ? cm3/m3-sys/m3tests/m3tests-results.xml 36 ? cm3/m3-sys/m3tests/m3tests-results.xml.new 37 ? cm3/m3-sys/m3tests/m3tests.html 38 ? cm3/m3-tools/cvsup/cvpasswd/PPC_LINUX 39 ? cm3/m3-tools/kate/PPC_LINUX 40 ? cm3/m3-tools/m3tohtml/html we might consider having the scripts delete such things at the start of a run. Including what .cvsignore is suppressing (depending on if the desire is to clean or not). Notice that not all are in the derived directory (or rather none are, except the derived directory itself) - Jay From rcoleburn at scires.com Mon Jul 27 18:29:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 27 Jul 2009 12:29:41 -0400 Subject: [M3devel] the formsedit crash In-Reply-To: References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> Message-ID: <4A6D9D4E.1E75.00D7.1@scires.com> In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. See the code snippet below: (* stack *) IF pp.keywordPresent("-stack") THEN (* *) TRY (* *) stackMult := pp.getNextInt(min := 1, max := 100); EXCEPT | ParseParams.Error => (* *) pp.error("A number in the range [1..100] must be specified as\n" & "the stack size multiplier after the -stack option.\n"); END; (* try *) END; (* if *) IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy Coleburn >>> Jay K 7/27/2009 11:24 AM >>> I don't think this is a stack overflow but I will try that. We should probably drastically increase the defaults. Like make them match whatever the underlying platform uses, or just make sure that unless the user intercedes, that we don't either. The whole notion of a limited size stack is pretty flawed imho. And much worse if you engage in reducing it from the default. How much stack do I need to leave for fopen to work? What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. - Jay ---------------------------------------- > Date: Mon, 27 Jul 2009 16:53:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > Quoting Tony Hosking : > >> Not sure if doing it that way works. Current default stack size set in >> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >> changing it there. > > There used to be a procedure IncreaseDefaultStackSize. IITR we needed > that for several M3 applications on some platforms several years ago. > > But probably we should also set the default for a target platform > so that all our own applications are able to run. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 27 18:33:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:33:43 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <4A6D9D4E.1E75.00D7.1@scires.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> <4A6D9D4E.1E75.00D7.1@scires.com> Message-ID: > a command line parameter to set the stack size! This is proof that the mechanism is very flawed. Imagine if all programs accepted a command line parameter to set their stack size, and chosing the right number was critical to their successful operation. !!! - Jay ________________________________ > Date: Mon, 27 Jul 2009 12:29:41 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] the formsedit crash > > > > > > > > In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. > > > > If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. > > > > See the code snippet below: > > > > (* stack *) > IF pp.keywordPresent("-stack") > THEN (* *) > TRY (* *) > stackMult := pp.getNextInt(min := 1, max := 100); > EXCEPT > | ParseParams.Error => (* *) > pp.error("A number in the range [1..100] must be specified as\n" > & "the stack size multiplier after the -stack option.\n"); > END; (* try *) > END; (* if *) > IF stackMult> 1 > THEN > WITH default = Thread.GetDefaultStackSize(), > desired = default * stackMult, > increase = desired - default > DO > PutText("Increasing default stack size by a factor of " & > Fmt.Int(stackMult) & " (" & Fmt.Int(default) & ">>> " & > Fmt.Int(desired) & ").\n"); > Thread.IncDefaultStackSize(increase); > END; (* with *) > WITH default = Thread.GetDefaultStackSize() > DO > PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); > END; (* with *) > END; (* if *) > > > > Regards, > > Randy Coleburn > >>>> Jay K 7/27/2009 11:24 AM>>> > > I don't think this is a stack overflow but I will try that. > We should probably drastically increase the defaults. > Like make them match whatever the underlying platform uses, or just make > sure that unless the user intercedes, that we don't either. > > > The whole notion of a limited size stack is pretty flawed imho. > And much worse if you engage in reducing it from the default. > How much stack do I need to leave for fopen to work? > What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. > Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). > I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) > > > Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. > What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 27 Jul 2009 16:53:08 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> Quoting Tony Hosking : >> >>> Not sure if doing it that way works. Current default stack size set in >>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >>> changing it there. >> >> There used to be a procedure IncreaseDefaultStackSize. IITR we needed >> that for several M3 applications on some platforms several years ago. >> >> But probably we should also set the default for a target platform >> so that all our own applications are able to run. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Mon Jul 27 18:44:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 16:44:57 +0000 Subject: [M3devel] bad web pages Message-ID: [ sorry if this too rude. I've been avoiding saying anything because I haven't done anything to fix it and because my complaints are a little vague. But I am sure there is something significant here. When something bugs I often wait and see if it stops bugging me, maybe I overreact initially. But this has continued to bug me. ] I'm sorry, but our web pages are not very good. Too much information, too many details presented too early, hard to see the little a new person needs. I don't have the patience right now to go into detail, but starting here: http://www.opencm3.net/releng/ Much too much stuff. Beginners need to quickly get to a download, and quickly have hello world working, and then a link to the language and library documentation. Telling them about packages early is not useful. Having so many options as to what to download is not useful. I admit even my min vs. std separation is not great. It is embarassing either way -- either you are a huge download or you have pitiful little functionality. Though libm3 is not exactly pitiful I gather. They don't care much about quake. Just give one or two quick tutorial examples: - here is how you build a program from multiple source files - optionally here is how you build a library (obviously this information must be provided, but not super early) My other complaint is that I go here: http://modula3.elegosoft.com/ and there is a link "WWW service for CM3 and PM3" Huh? WWW Service? Aren't I already there? Perhaps I just pick a bad starting point? Is the distinction Modula-3 the language vs. the two distributions CM3 and PM3? Maybe we should ignore PM3 and equate Modula-3 with CM3, and somehow merge this stuff? The package download service? Does anyone use it? The problem, the reason I don't rewrite stuff and am just a lazy complainer, is that in total there's a bunch of stuff in there. The way it is laid out is bad. It used to take me a while to find stuff. I can't be very concrete now..maybe the organization has changed..I thought it was the stuff you have to scroll to the bottom for, but I don't use that anymore. One concrete thing is that http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes doesn't need to be so visible, it's spot could be used for something of more general use. I realize that it was more valuable when 5.1 was new, and then its value degraded gradually. It depends how much there is out there that works with 3.x?4.x?PM3 and doesn't work with CM3? Perhaps a very big part of the answer here is deb packages? - add such and such line to whatever file - apt-get modula3-min or modula3-all, or whatever you want in-between? - apt-whatever -list modula3-*? I guess we'd have to call them cm3 not modula3. - Jay From jay.krell at cornell.edu Mon Jul 27 19:17:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 17:17:51 +0000 Subject: [M3devel] the formsedit crash In-Reply-To: <4A6D9D4E.1E75.00D7.1@scires.com> References: <88DDC05E-379A-421D-B1D4-380637455106@cs.purdue.edu> <20090727165308.5ex66bi27ascsk0o@mail.elegosoft.com> <4A6D9D4E.1E75.00D7.1@scires.com> Message-ID: > I don't know of a way to increase the mainline thread stack while it is running. On NT you cannot. The stack size is set when the thread is created. Once the thread is created, that is it. Typical default thread sizes on 32bit NT are 256K and 1MB. Maybe twice that for 64bit. I think there might be a minimum that small requests get rounded up to. VirtualAlloc basically allocates in 64K chunks so you can't likely get smaller than 64K, or 60K if you consider the guard page. Some experimentation would be informative. I've seen gcc stack overflow only on non-Linux..because the default stack on Linux is huge, like 8MB. I guess that's what you get in historically single threaded environments.. If you write an NT kernel driver, then you generally have like 3 4K pages maximum, a very different environment. Basically I consider this area fairly unpredictable. Did I create the thread or did someone else create it and call me? How much stack is required by the code I'm going to call. In the absence of any solutions, best advise for the programmer is to generally conserve stack. If you must recurse, recurse only to a maximum amount determined by your code, not determined by user input. Otherwise large user input will cause you to fail in a hard to handle way. Fixed sized character buffers of 256, 1024, MAX_PATH, etc. are not a good thing to use. Doubly (or even quadruply) bad with Unicode. Despite being very fast. Another option is to use a small buffer like 64 and then heap alloc if the data is large. Or just heap alloc and have a smooth if slow performance curve against data size. At least with the heap, it is pretty much limited by address space, and running out of heap at least in C is very well defined -- you get NULL from malloc. Many people know to check for that. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] the formsedit crash > Date: Mon, 27 Jul 2009 16:33:43 +0000 > > >> a command line parameter to set the stack size! > > This is proof that the mechanism is very flawed. > Imagine if all programs accepted a command line parameter to set their stack size, and chosing the right number was critical to their successful operation. > > !!! > > - Jay > > > > ________________________________ >> Date: Mon, 27 Jul 2009 12:29:41 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] the formsedit crash >> >> >> >> >> >> >> >> In my applications, I added code to accept a command line parameter for increasing the stack size. Internally, I call the procedures from the Thread interface to increase the stack size. I had to do this to avoid running out of stack, esp. when using Trestle/FormsVBT. I found that I had to multiply the stack size by a factor of 7 for most of my stuff to work. Note that this increase applies to new threads, not to the mainline thread. I don't know of a way to increase the mainline thread stack while it is running. >> >> >> >> If there is a change to the default stack size, anyone who does similar tricks will need to modify their code, or their shortcuts, or scripts to avoid making the stack too big. >> >> >> >> See the code snippet below: >> >> >> >> (* stack *) >> IF pp.keywordPresent("-stack") >> THEN (* *) >> TRY (* *) >> stackMult := pp.getNextInt(min := 1, max := 100); >> EXCEPT >> | ParseParams.Error => (* *) >> pp.error("A number in the range [1..100] must be specified as\n" >> & "the stack size multiplier after the -stack option.\n"); >> END; (* try *) >> END; (* if *) >> IF stackMult> 1 >> THEN >> WITH default = Thread.GetDefaultStackSize(), >> desired = default * stackMult, >> increase = desired - default >> DO >> PutText("Increasing default stack size by a factor of " & >> Fmt.Int(stackMult) & " (" & Fmt.Int(default) & ">>> " & >> Fmt.Int(desired) & ").\n"); >> Thread.IncDefaultStackSize(increase); >> END; (* with *) >> WITH default = Thread.GetDefaultStackSize() >> DO >> PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); >> END; (* with *) >> END; (* if *) >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay K 7/27/2009 11:24 AM>>> >> >> I don't think this is a stack overflow but I will try that. >> We should probably drastically increase the defaults. >> Like make them match whatever the underlying platform uses, or just make >> sure that unless the user intercedes, that we don't either. >> >> >> The whole notion of a limited size stack is pretty flawed imho. >> And much worse if you engage in reducing it from the default. >> How much stack do I need to leave for fopen to work? >> What do I do when I run out of stack? On NT you can detect and handle it, but it is too tricky. >> Personally I try to use very little stack, and don't use recursion - if I must use a "heap allocated stack" (e.g. std::stack<> in C++). >> I understand though that the machine stack is tremendously faster than anything heap-based (at least in non-gc environments, gc heap alloc can be fast, if you don't mind the extra work for the gc to later clean it up..and if the usage is actually lifo...) >> >> >> Granted, if I'm "just doing a bunch of math" and don't call into code I don't control, then it becomes more tenable. Still hard to pick a size that is portable, though multiplying by sizeof(void*) helps. >> What if I use TRY? That uses a highly platform-specific and often fairly large amount of stack. >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Mon, 27 Jul 2009 16:53:08 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] the formsedit crash >>> >>> Quoting Tony Hosking : >>> >>>> Not sure if doing it that way works. Current default stack size set in >>>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try >>>> changing it there. >>> >>> There used to be a procedure IncreaseDefaultStackSize. IITR we needed >>> that for several M3 applications on some platforms several years ago. >>> >>> But probably we should also set the default for a target platform >>> so that all our own applications are able to run. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From eiserlohpp at yahoo.com Mon Jul 27 20:49:57 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 27 Jul 2009 11:49:57 -0700 (PDT) Subject: [M3devel] compiler status lines, output in a burst Message-ID: <34573.39026.qm@web56805.mail.re3.yahoo.com> Hi Guys, I just downloaded the latest tarball, and started compiling it with a compiler built from 20090724 (three days ago). I noticed that the output looked "jerky", unlike the normal behavior. Looking closer, it appears that the compiler descends into a package, announces that it has started, then waits. A few seconds later it emits all the ( new-source -> foo.[im]3 ) and similar lines in one burst. Did someone remove the flush at the end of a line of text? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Mon Jul 27 22:07:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:07:26 +0200 Subject: [M3devel] compiler status lines, output in a burst In-Reply-To: <34573.39026.qm@web56805.mail.re3.yahoo.com> References: <34573.39026.qm@web56805.mail.re3.yahoo.com> Message-ID: <20090727220726.fu6kbgwr3koooowg@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Guys, > > I just downloaded the latest tarball, and started compiling > it with a compiler built from 20090724 (three days ago). > > I noticed that the output looked "jerky", unlike the > normal behavior. Looking closer, it appears that the > compiler descends into a package, announces that it has > started, then waits. A few seconds later it emits all > the ( new-source -> foo.[im]3 ) and similar lines in > one burst. > > Did someone remove the flush at the end of a line of text? That should be fixed easily. Stay tuned, just waiting for a test in Hudson... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 22:49:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:49:26 +0200 Subject: [M3devel] bad web pages In-Reply-To: References: Message-ID: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> No offense taken. Any volunteers for working on improving the web presentation are welcome. The official domains are opencm3.net and modula3.org. Everything else should be left to Elego. I'd really appreciate if someone with the appropriate knowledge in design would step in. I don't think anybody is interested in doing that, though. I'd say that 99% of what is there has been structured and presented by me in the simplest way just to publish the available information at all. Some people have made concrete change suggestions, and I'm usually trying to follow and integrate them. Let's not try a complete overhaul for this release. Just fix the most blatant errors and no-gos. Everything else will take months. The releng pages have been open for discussion here for several weeks now; they are still not public (i.e. not linked to the other pages) of opencm3.net. Suggestions may also simply be checked in (everything is in the repo), preferrably on a branch, so that everyone can have a look at it. It's also much more effective. I haven't got the time to process half a dozen of new and probably conflicting suggestions. What's not open for discussion in my eyes any more is the structure of the release archives. We'll just use what is described there, or it will take months till we get anywhere. It will also be the last time that I coordinate a CM3 release. Everyone around me is already complaining :-( Olaf Quoting Jay K : > [ > sorry if this too rude. > I've been avoiding saying anything because I haven't done anything > to fix it and because my complaints are a little vague. But I am > sure there is something significant here. When something bugs I > often wait and see if it stops bugging me, maybe I overreact > initially. But this has continued to bug me. > ] > > > I'm sorry, but our web pages are not very good. > Too much information, too many details presented too early, hard to > see the little a new person needs. > > > I don't have the patience right now to go into detail, but starting here: > > > http://www.opencm3.net/releng/ > > > Much too much stuff. > > > Beginners need to quickly get to a download, and quickly have hello > world working, and then a link to the language and library > documentation. > > > Telling them about packages early is not useful. > Having so many options as to what to download is not useful. > I admit even my min vs. std separation is not great. > It is embarassing either way -- either you are a huge download or > you have pitiful little functionality. Though libm3 is not exactly > pitiful I gather. > > > They don't care much about quake. > Just give one or two quick tutorial examples: > - here is how you build a program from multiple source files > - optionally here is how you build a library (obviously this > information must be provided, but not super early) > > > My other complaint is that I go here: > > > http://modula3.elegosoft.com/ > > > and there is a link "WWW service for CM3 and PM3" > > Huh? WWW Service? Aren't I already there? > Perhaps I just pick a bad starting point? > > > Is the distinction Modula-3 the language vs. the two distributions > CM3 and PM3? > Maybe we should ignore PM3 and equate Modula-3 with CM3, and somehow > merge this stuff? > > > The package download service? Does anyone use it? > > > The problem, the reason I don't rewrite stuff and am just a lazy > complainer, is that in total there's a bunch of stuff in there. The > way it is laid out is bad. It used to take me a while to find stuff. > > > I can't be very concrete now..maybe the organization has changed..I > thought it was the stuff you have to scroll to the bottom for, but I > don't use that anymore. > > > One concrete thing is that > http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes doesn't > need to be so > visible, it's spot could be used for something of more general use. > I realize that it was more valuable when 5.1 was new, and then its > value degraded gradually. > It depends how much there is out there that works with 3.x?4.x?PM3 > and doesn't work with CM3? > > > > Perhaps a very big part of the answer here is deb packages? > - add such and such line to whatever file > - apt-get modula3-min or modula3-all, or whatever you want in-between? > - apt-whatever -list modula3-*? > > > I guess we'd have to call them cm3 not modula3. > > > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 27 22:50:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Jul 2009 22:50:23 +0200 Subject: [M3devel] compiler status lines, output in a burst In-Reply-To: <34573.39026.qm@web56805.mail.re3.yahoo.com> References: <34573.39026.qm@web56805.mail.re3.yahoo.com> Message-ID: <20090727225023.zf2wctvsisgswckw@mail.elegosoft.com> Quoting Peter Eiserloh : > I noticed that the output looked "jerky", unlike the > normal behavior. Looking closer, it appears that the > compiler descends into a package, announces that it has > started, then waits. A few seconds later it emits all > the ( new-source -> foo.[im]3 ) and similar lines in > one burst. should be fixed now Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 28 01:10:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Jul 2009 23:10:15 +0000 Subject: [M3devel] getting Tinderbox to green? Message-ID: Linux/x86, Linux/sparc, Linux/ppc. Sparc hit access denied uploading to birch. Maybe transient network problem. The others succeeded builds, failed tests. Failed tests is normal, right? And should be green? They stay orange. I also see that the yellow doesn't change to green or orange until the next build is started, I'm pretty sure. I somehow got very luck with my one SOLgnu run. It was green on almost my first try. - Jay From jay.krell at cornell.edu Tue Jul 28 05:09:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 03:09:36 +0000 Subject: [M3devel] getting Tinderbox to green? Message-ID: I think on PPC_LINUX I just need to delete the old pkg and lib stores particularly to remove the old libodbc.so. On I386_LINUX there is a different problem linking the db test. I might have to install something extra there. Could be a Gentoo vs. Debian thing. Not likely any real problem in the Modula-3 tree here, but a problem with my machine configuration. SPARC32_LINUX's last run that uploaded had the m3gdb problem, so still waiting to see. Maybe the next runs will go green, maybe. btw, I'm pretty sure this is all feeds directly into Hudson, like, I'm not wasting time on Tinderbox. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: getting Tinderbox to green? > Date: Mon, 27 Jul 2009 23:10:15 +0000 > > > Linux/x86, Linux/sparc, Linux/ppc. > Sparc hit access denied uploading to birch. > Maybe transient network problem. > > The others succeeded builds, failed tests. > Failed tests is normal, right? > And should be green? > They stay orange. > I also see that the yellow doesn't change to green or orange > until the next build is started, I'm pretty sure. > > I somehow got very luck with my one SOLgnu run. > It was green on almost my first try. > > > - Jay > From rcoleburn at scires.com Tue Jul 28 05:24:26 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 27 Jul 2009 23:24:26 -0400 Subject: [M3devel] new install on Windows Vista Message-ID: <4A6E36C0.1E75.00D7.1@scires.com> Jay: I am attempting a new install on Windows Vista. I have a question about the config files. I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? Thanks for your help! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 06:22:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 04:22:25 +0000 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6E36C0.1E75.00D7.1@scires.com> References: <4A6E36C0.1E75.00D7.1@scires.com> Message-ID: [keeping you on the thread in case of truncation] I would do all the clean each package first, then build and ship each, two passes over the list clean in the first pass build and ship in the second That is hard to explain clearly but I think you understand. Given the packages a b c. clean a clean b clean c build a ship a build b ship b build c ship c is what I do, but it should also work as: clean a build a ship a clean b build b ship b clean c build c ship c which is what I think you described. My python files do deal with the config files. You might try reading some of it? (not intended rudely, as evidenced by further explanation here) Here is the current way: for each file name in cvsroot\m3-sys\cminstall\src\config-no-install and cvsroot\m3-sys\cminstall\src\config delete corresponding file in \cm3\bin That is a "cleanup" step. Not applicable if starting from scratch, harmless. mkdir \cm3\bin\config copy cvsroot\m3-sys\cminstall\src\config-no-install \cm3\bin\config create \cm3\bin\cm3.cfg with the following exact contents: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) There is no meta syntax there. - forward slashes work on Windows - path() is a function that returns the directory of the file calling it - HOST is builtin on newer builds and is a good default for TARGET (We should use this in the distribution archives.) Some of this is taste and the system is flexible. If you wanted, you could put all the files in \cm3\bin, or \whatever. You can make cm3.cfg look in various places. That is what I actually do -- I copy cvsroot\m3-sys\cminstall\src\config-no-install\cm3.cfg to \cm3\bin. It ends up picking up %CM3_ROOT%\m3-sys\cminstall\src\config-no-install\TARGET, so I can edit just one file while in development and not keep having to copy it around. Otherwise I'd get an error in one file in \cm3\bin, fix it, and then remember to copy it into the source tree to check it in. > esp. given an aribitrary old minimal installation as a starting point Yes. I recently removed a lot of the very old compatibility but I have used these exact config files with fairly old builds and run upgrade.cmd or upgrade.py. They were meant to work with a wide range of cm3 versions and on multiple platforms. If you want I can put the compatibility back. There were workarounds for bugs, not yet provided features, etc. The workarounds dynamically adapted to what capabilities the cm3/cm3cg they were using had, and they new for newer platforms to just assume things work well. There are more newer platforms than older platforms so it was kind of annoying to carry it all around, but it does work. I can put it back. You might also want to read README.jay that I checked in. I'll summarize it here: create new empty directory, and bin and bin\config thereof. Put cm3 and cm3cg in bin, copy all the config files to bin\config, create cm3.cfg as shown earlier. Given a recent cm3 (e.g. one that supports LONGINT) that is all you need to build the system starting with import-libs or m3core and on up. (import-libs is almost unnecessary. It is a workaround for that - older cm3 builds contained bogus files - some but very few native toolsets don't have the requisite files, like Visual C++ 2003 Express If you have a decent toolset and start with an old cm3, you can just delete the toplevel lib directory to get started and skip import-libs..but it builds super fast anyway). You don't likely even need cm3cg, it just saves time. And you don't need it on NT386 of course. If you have too old of a cm3, then you start with cm3 and pkg\m3core and pkg\libm3, and start with import-libs and sysutils, skipping m3core and libm3. (I'm assuming both m3core and libm3 use LONGINT, if they don't, then..) Oh, also older and even current cm3 can't build certain versions of m3core and/or libm3 (I think just libm3) between old and present due to the platform list. But current m3core and libm3 don't have that problem. m3-sys\cminstall\src\config is dead, as are all the config files around m3-sys\cm3\config. I deleted m3-sys\cm3\config but Tony added some back. I'm trying to wait until after this release to delete a lot of the dead stuff. Trying also to consider if some of it has historical/reference value. Like all the Unix *.i3 files. Maybe just comment those all out instead of deleting them. I know there is CVS history but it much easier to see what is dead and present than dead and gone, as long as there are good hints that it is dead, like commenting out every line. "a lot has changed in the config files since 5.8.1" I imagine would be - removal of compatibility stuff - possibly the use of symlinks and removal of hardlinks - having make_lib call skip_lib - oh, right, refactoring of all the toplevel files to include(architecture) and include(os). That had been bugging me for a long time so I finally did it. Basically the original authors of the config files either - liked monolithic files - didn't consider the proliferation of OS across multiple/many architectures These days we have fairly few OS, but many OS x architecture. NetBSD on everything, Linux on everything, everything else still on a few Let me know if that doesn't answer everything or if you have further questions. Once I have the Tinderbox runs running better on Posix sysetms, I will face the choice for NT386 of using Cygwin sh to drive it all, or rewriting all the .sh in .cmd or .py or .js. I'm strongly considering rewriting in .py. Rewriting is also a good way to gain understanding, you have to read and understand every line. - Jay ________________________________ > Date: Mon, 27 Jul 2009 23:24:26 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] new install on Windows Vista > > > > > > > > Jay: > > > > I am attempting a new install on Windows Vista. I have a question about the config files. > > > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > > > It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. > > > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > > > Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. > > > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. > > > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? > > > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? > > > > Thanks for your help! > > > > Regards, > > Randy Coleburn From lists at darko.org Tue Jul 28 06:47:08 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 06:47:08 +0200 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6E36C0.1E75.00D7.1@scires.com> References: <4A6E36C0.1E75.00D7.1@scires.com> Message-ID: <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> I happen to be doing the same thing at the moment (on XP). Have we got an installer for this in the works? And Inno Setup one should be pretty easy if not. On 28/07/2009, at 5:24 AM, Randy Coleburn wrote: > Jay: > > I am attempting a new install on Windows Vista. I have a question > about the config files. > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > It is unzipped to C:\cm3. Note that I also have a complete checkout > of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also > installed Visual C++ 2008 Express. > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C: > \cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, > hoping that this will indeed upgrade the compiler in the proper > order, based on PkgInfo.txt. If I invoke my script as follows "do- > cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 - > build", and "cm3 -ship" command sequence to each package identified > in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > Perhaps this is a flawed plan; if so, let me know. I know there are > various scripts and python that may already purport to do what I > want to do, but please humor me. I am trying to learn the actual > low-level steps required to do the install and upgrade, beginning > with the minimal distribution. In my view, once I have the minimal > binary distro plus the new sources, I ought to be able to use the > cm3 commands (perhaps scripted) to rebuild everything properly, as > long as I do it in the correct order. > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin > \cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C: > \Sandbox\m3-sys\cminstall\src" we have a config folder and a config- > no-install folder. In the past, I've been copying the contents of > the config-no-install folder to "C:\cm3\bin". (1) Is this correct? > If not, please explain. > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If > not, how/when/should this folder be updated? > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, > it seems a lot has changed, hence my questions. I also wonder that > if someone used the python or other scripts, do these handle > updating the various config stuff, esp. given an aribitrary old > minimal installation as a starting point? > > Thanks for your help! > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 07:04:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 05:04:49 +0000 Subject: [M3devel] new install on Windows Vista In-Reply-To: <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> References: <4A6E36C0.1E75.00D7.1@scires.com> <2321ACAD-CEE9-4A91-AA5E-1BFD6E36F3D3@darko.org> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi created by automation in cvsroot/scripts/python/pylib.py, via scripts/python/make-dist.py. - Jay ________________________________ > From: lists at darko.org > To: m3devel at elegosoft.com > Date: Tue, 28 Jul 2009 06:47:08 +0200 > Subject: Re: [M3devel] new install on Windows Vista > > I happen to be doing the same thing at the moment (on XP). Have we got an installer for this in the works? And Inno Setup one should be pretty easy if not. > > > On 28/07/2009, at 5:24 AM, Randy Coleburn wrote: > > Jay: > > I am attempting a new install on Windows Vista. I have a question about the config files. > > I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip > > It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express. > > My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt. > > Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order. > > Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain. > > (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated? > > (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point? > > Thanks for your help! > > Regards, > Randy Coleburn > From wagner at elegosoft.com Tue Jul 28 07:24:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 07:24:59 +0200 Subject: [M3devel] getting Tinderbox to green? In-Reply-To: References: Message-ID: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> Quoting Jay K : > Linux/x86, Linux/sparc, Linux/ppc. > Sparc hit access denied uploading to birch. > Maybe transient network problem. > > The others succeeded builds, failed tests. > Failed tests is normal, right? > And should be green? > They stay orange. That's expected. All release builds were orange as long as I remember. We always had failed tests. > I also see that the yellow doesn't change to green or orange > until the next build is started, I'm pretty sure. That's strange. It should get green/orange/red as soon as the results are in. > I somehow got very luck with my one SOLgnu run. > It was green on almost my first try. So it doesn't run any tests? Just compiles? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lists at darko.org Tue Jul 28 07:24:25 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 07:24:25 +0200 Subject: [M3devel] bad web pages In-Reply-To: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> References: <20090727224926.yp4u8bvfsgog0c0g@mail.elegosoft.com> Message-ID: I don't think the visiual presentation is the issue, but the oganisation could be improved. I think visiually it should look like the M3 Language Definition and the like. I'll have a go at re- organising it. On 27/07/2009, at 10:49 PM, Olaf Wagner wrote: > No offense taken. Any volunteers for working on improving the > web presentation are welcome. > > The official domains are opencm3.net and modula3.org. > Everything else should be left to Elego. > > I'd really appreciate if someone with the appropriate knowledge > in design would step in. I don't think anybody is interested in > doing that, though. I'd say that 99% of what is there has been > structured and presented by me in the simplest way just to publish > the available information at all. > > Some people have made concrete change suggestions, and I'm usually > trying to follow and integrate them. > > Let's not try a complete overhaul for this release. Just fix the most > blatant errors and no-gos. Everything else will take months. > > The releng pages have been open for discussion here for several weeks > now; they are still not public (i.e. not linked to the other pages) > of opencm3.net. > > Suggestions may also simply be checked in (everything is in the repo), > preferrably on a branch, so that everyone can have a look at it. > It's also much more effective. I haven't got the time to process > half a dozen of new and probably conflicting suggestions. > > What's not open for discussion in my eyes any more is the structure > of the release archives. We'll just use what is described there, > or it will take months till we get anywhere. It will also be the > last time that I coordinate a CM3 release. Everyone around me is > already complaining :-( > > Olaf > > Quoting Jay K : > >> [ >> sorry if this too rude. >> I've been avoiding saying anything because I haven't done anything >> to fix it and because my complaints are a little vague. But I am >> sure there is something significant here. When something bugs I >> often wait and see if it stops bugging me, maybe I overreact >> initially. But this has continued to bug me. >> ] >> >> >> I'm sorry, but our web pages are not very good. >> Too much information, too many details presented too early, hard >> to see the little a new person needs. >> >> >> I don't have the patience right now to go into detail, but starting >> here: >> >> >> http://www.opencm3.net/releng/ >> >> >> Much too much stuff. >> >> >> Beginners need to quickly get to a download, and quickly have >> hello world working, and then a link to the language and library >> documentation. >> >> >> Telling them about packages early is not useful. >> Having so many options as to what to download is not useful. >> I admit even my min vs. std separation is not great. >> It is embarassing either way -- either you are a huge download or >> you have pitiful little functionality. Though libm3 is not exactly >> pitiful I gather. >> >> >> They don't care much about quake. >> Just give one or two quick tutorial examples: >> - here is how you build a program from multiple source files >> - optionally here is how you build a library (obviously this >> information must be provided, but not super early) >> >> >> My other complaint is that I go here: >> >> >> http://modula3.elegosoft.com/ >> >> >> and there is a link "WWW service for CM3 and PM3" >> >> Huh? WWW Service? Aren't I already there? >> Perhaps I just pick a bad starting point? >> >> >> Is the distinction Modula-3 the language vs. the two distributions >> CM3 and PM3? >> Maybe we should ignore PM3 and equate Modula-3 with CM3, and >> somehow merge this stuff? >> >> >> The package download service? Does anyone use it? >> >> >> The problem, the reason I don't rewrite stuff and am just a lazy >> complainer, is that in total there's a bunch of stuff in there. >> The way it is laid out is bad. It used to take me a while to find >> stuff. >> >> >> I can't be very concrete now..maybe the organization has >> changed..I thought it was the stuff you have to scroll to the >> bottom for, but I don't use that anymore. >> >> >> One concrete thing is that http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes >> doesn't need to be so >> visible, it's spot could be used for something of more general use. >> I realize that it was more valuable when 5.1 was new, and then its >> value degraded gradually. >> It depends how much there is out there that works with 3.x?4.x?PM3 >> and doesn't work with CM3? >> >> >> >> Perhaps a very big part of the answer here is deb packages? >> - add such and such line to whatever file >> - apt-get modula3-min or modula3-all, or whatever you want in- >> between? >> - apt-whatever -list modula3-*? >> >> >> I guess we'd have to call them cm3 not modula3. >> >> >> - Jay >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Jul 28 07:41:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 05:41:44 +0000 Subject: [M3devel] getting Tinderbox to green? In-Reply-To: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> References: <20090728072459.htpblk3xck8wgcs8@mail.elegosoft.com> Message-ID: > That's expected. All release builds were orange as long as I remember. > We always had failed tests. But your builds are green. I think there might be two measures of test failure. Building the tests vs. running the tests? I still have build failures wrt db. I think that is holding it up. Tony's Solaris runs do too. http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-SOLgnu.html#tr_m3-db-odbc >> I somehow got very luck with my one SOLgnu run. >> It was green on almost my first try. > So it doesn't run any tests? Just compiles? Yeah you are right: [start run-tests 2009.07.26 05:08:06] 6600 cd /tmp/build-cm3-20090726-031802-jMaOBg/build 6601 [end run-tests 2009.07.26 05:08:06] I must have forgotten to comment out to run the tests. I think the reason my earlier builds never finished was probably they were hung trying to scp/ssh to birch without the username fixed. I thought it was something related to not running the tests, but now I doubt that. I guess the way to get green asap is remove that edit and don't run the tests at all. I'll try not to go that way though. Hot weather this week also, not sure what I'm going to do.. - Jay From eiserlohpp at yahoo.com Tue Jul 28 08:37:08 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 27 Jul 2009 23:37:08 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 33, Issue 104 Message-ID: <28748.61011.qm@web56806.mail.re3.yahoo.com> Hi Olaf, I just wanted to say thank you! You have been doing a great job. A compiler and development environment such as CM3 is a very large software suite, and to coordinate a software release is never an easy job. Sure the web pages can use some sprucing up, big deal! Like you said, all the web pages are in the CVS repo, any one with write access to the repo could change them. It may seem like there is a lot of complaining, and it is, but what has everyone jazzed up at the moment (okay last few months), is that shortly, all the work we have been doing will be seeing a much larger audience, and we want our favorite project to look its best. What we all should remember is that we all have real lives, away from the computer and modula-3. None of us has enough time to do _everything_ we want. BTW: I just wanted bring your attention to my latest build of Debian packages for AMD64_LINUX on "lenny". I built it today from cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. http://www.eiserloh.org/mirrors/modula3/ If you have a Debian-lenn-AM64 machine, could you try it out. Maybe, even download the source package, and try building it yourself. The source package should work with any architecture supported by Debian. Please comment on any improvements I can make to these debian packages. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > Date: Mon, 27 Jul 2009 22:49:26 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] bad web pages It will also be the > last time that I coordinate a CM3 release. Everyone around > me is already complaining :-( > > Olaf From lists at darko.org Tue Jul 28 09:24:38 2009 From: lists at darko.org (Darko Volaric) Date: Tue, 28 Jul 2009 09:24:38 +0200 Subject: [M3devel] Dependency on msvcr80.dll Message-ID: After intalling the latest VC++ Express which is 2008 or version 9 and building with your min distribution I found it was dependent on msvcr80.dll. Is this hard coded somewhere - should it use the msvcr90.dll? Is there a correct way to resolve it? Cheers, Darko. From jay.krell at cornell.edu Tue Jul 28 09:28:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 07:28:25 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: This is a problem I found and reported here last week. Until otherwise figured out, we have to provide a build per supported toolset/runtime. It is built into the binaries/libraries, it is their dependencies. I don't fully understand what is going on. Just because m3core.dll uses a particular .dll, does not foist that direct dependency on its users. However if you want to get malloced pointer from it and then free it, or an fopen FILE* from it and fread/fclose it, then you do have to agree. malloc is very easy to do without, and besides, most/all of this stuff is wrapped up -- you know, if you call UntracedHeapAllocate (whatever it is called) you can't then call free, you have to call UntracedHeapFree (whatever it is called) - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Subject: Dependency on msvcr80.dll > Date: Tue, 28 Jul 2009 09:24:38 +0200 > CC: m3devel at elegosoft.com > > After intalling the latest VC++ Express which is 2008 or version 9 and > building with your min distribution I found it was dependent on > msvcr80.dll. Is this hard coded somewhere - should it use the > msvcr90.dll? Is there a correct way to resolve it? > > Cheers, > Darko. > From jay.krell at cornell.edu Tue Jul 28 09:28:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 07:28:54 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: (and I opened a Trac ticket too) ---------------------------------------- > From: jay.krell at cornell.edu > To: lists at darko.org > CC: m3devel at elegosoft.com > Subject: RE: Dependency on msvcr80.dll > Date: Tue, 28 Jul 2009 07:28:25 +0000 > > > This is a problem I found and reported here last week. > > > Until otherwise figured out, we have to provide a build per supported toolset/runtime. > It is built into the binaries/libraries, it is their dependencies. > > > I don't fully understand what is going on. > > > Just because m3core.dll uses a particular .dll, does not foist that direct dependency on its users. However if you want to get malloced pointer from it and then free it, or an fopen FILE* from it and fread/fclose it, then you do have to agree. > > > malloc is very easy to do without, and besides, most/all of this stuff is wrapped up -- you know, if you call UntracedHeapAllocate (whatever it is called) you can't then call free, you have to call UntracedHeapFree (whatever it is called) > > > - Jay > > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Subject: Dependency on msvcr80.dll >> Date: Tue, 28 Jul 2009 09:24:38 +0200 >> CC: m3devel at elegosoft.com >> >> After intalling the latest VC++ Express which is 2008 or version 9 and >> building with your min distribution I found it was dependent on >> msvcr80.dll. Is this hard coded somewhere - should it use the >> msvcr90.dll? Is there a correct way to resolve it? >> >> Cheers, >> Darko. >> From jay.krell at cornell.edu Tue Jul 28 11:35:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 09:35:31 +0000 Subject: [M3devel] odbc errors Message-ID: odbc errors Tony, everyone, please read and then do like this: rm -rf /usr/local/cm3/pkg/*odbc* rm -rf /usr/local/cm3/lib/*odbc* cd root/cm3/m3-db rm -rf odbc cvs -z3 upd -dAP odbc cd odbc cm3 cm3 -ship cd ~/work/cm3-inst find . | grep odbc | xargs rm - Jay From hendrik at topoi.pooq.com Tue Jul 28 11:39:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Jul 2009 05:39:32 -0400 Subject: [M3devel] making cvs checkout/update more robust in tinderbox (and maybe Hudson) In-Reply-To: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> References: <20090727153155.vcxvvlh08cs0w0k8@mail.elegosoft.com> Message-ID: <20090728093932.GA7708@topoi.pooq.com> On Mon, Jul 27, 2009 at 03:31:55PM +0200, Olaf Wagner wrote: > Quoting Jay K : > > >CVS checkout and update of an entire tree seem to be extremely unreliable. > >It takes a while and often times out. > > It should not take longer than about 5 minutes, and considering > the number of files and amount of data to be transferred, that's > quite acceptable. > > If we really run out of resources on birch, we may need to set up > a public r/o copy of the repository for cvs access. Or switch to a distrubited system like monotone, which I've been able to spend far too little time on lately. Sorry. -- hendrik From jay.krell at cornell.edu Tue Jul 28 11:40:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 09:40:33 +0000 Subject: [M3devel] odbc errors In-Reply-To: References: Message-ID: In the cm3-inst case you can just rm -rf */lib */pkg. You don't need them at the start of a Tinderbox run, at least not for last-ok. You do need them for last-rel I believe though (I've never run that). I've also deleted my entire lib and pkg install for good measure, but I know I can easily rebuild them and the "work/cm3-inst" is more important right now, that's where Tinderbox/Hudson work. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Tue, 28 Jul 2009 09:35:31 +0000 > Subject: [M3devel] odbc errors > > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay From jay.krell at cornell.edu Tue Jul 28 12:40:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 10:40:40 +0000 Subject: [M3devel] executable named "test" Message-ID: I noticed I had an executable named "test" in my cm3 install. It is related to caltech-parser, but I don't know exactly where it came from, or if it is still being produced. There is no capital P Program("test") just lowercase program("test") which means they only ship to the pkg directory and not bin. Just a note for folks to check for this and delete it. It probably only occurs if you have run the Tinderbox/Hudson stuff. And even then I'm not sure how/when/where/why. - Jay From hendrik at topoi.pooq.com Tue Jul 28 12:51:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Jul 2009 06:51:37 -0400 Subject: [M3devel] RC2 Release Engineering Status and Trac-king In-Reply-To: References: <20090718141822.78xnbfx8cg80sw8o@mail.elegosoft.com> Message-ID: <20090728105137.GC7708@topoi.pooq.com> On Sat, Jul 18, 2009 at 11:50:13PM +0000, Jay K wrote: > > cm3ide is quite unusual in being browser based and that really limits > it, esp. targeting browsers from long ago with just a bunch of html, > using Flash or Silverlight can result in a browser-based app as good > as a non-browser-based app. Please, don't require proprietary stuff in the browser. -- hendrik From jay.krell at cornell.edu Tue Jul 28 14:07:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 12:07:50 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: Try these that I just made? They were built with VC 9.0: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip I didn't test them (too much combinatorial explosion -- four things to test!) and the readme from before: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt Olaf, there is a LOT more in the snaps directory than the snapshot-index lists. A lot. Also my archives contain more of the licenses, so many that I put them in a subdirectory. - Jay From wagner at elegosoft.com Tue Jul 28 14:24:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 14:24:50 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: <20090728142450.ksxo5jvx8gkoksco@mail.elegosoft.com> Quoting Jay K : > Try these that I just made? > > They were built with VC 9.0: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip > > I didn't test them (too much combinatorial explosion -- four things to test!) > > and the readme from before: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt > > Olaf, there is a LOT more in the snaps directory than the > snapshot-index lists. > A lot. Also my archives contain more of the licenses, so many that I > put them in a subdirectory. Yes. Feel free to fix ;-) Or just open a ticket for the next release... It's probably just a pattern mismatch (snapshot lists, not copyrights). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 28 14:45:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 12:45:33 +0000 Subject: [M3devel] too many loops through packages? Message-ID: Tinderbox run..compile done, tests running..and I see m3gdb running configure. I think extra work is being done.. I guess it is a bunch of incremental builds and they don't take long? - Jay From wagner at elegosoft.com Tue Jul 28 15:05:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Jul 2009 15:05:38 +0200 Subject: [M3devel] too many loops through packages? In-Reply-To: References: Message-ID: <20090728150538.1h0ac4s2og0cg0os@mail.elegosoft.com> Quoting Jay K : > Tinderbox run..compile done, tests running..and I see m3gdb running > configure. > I think extra work is being done.. > I guess it is a bunch of incremental builds and they don't take long? There are not really incremental builds in Tinderbox. Everything is checked out fresh and built from scratch. And there are several tests performing the same builds with slightly different contexts or targets. I'm trying to make the Hudson builds a little bit more incremental. m3cc is already factored out; m3gdb should be, too. The rest (M3 :-) builds really fast. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Jul 28 15:39:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 09:39:45 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: Message-ID: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, so exactly what should I be deleting? And why? On 28 Jul 2009, at 05:35, Jay K wrote: > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 15:51:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Jul 2009 13:51:42 +0000 Subject: [M3devel] odbc errors In-Reply-To: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: Whereever you have it installed. The Modula-3 libodbc* was perhaps in conflict with other libodbc*. There were at least warnings to this affect in some builds. So it was renamed libm3odbc. However the old one isn't automatically deleted. I think we can always delete it -- assuming that cm3 libraries aren't in the same directory as non-cm3 libraries but Olaf said not to. If you look at your Solaris Tinderbox test results you will see some red I believe caused by this -- not deleting the old cm3 libodbc, whereever it is. I /think/ this failure to /build/ the tests is why the red or orange status on Tinderbox instead of green. But I'm not sure yet since I haven't gotten things to turn green yet. Maybe we can only get green on the builds that don't run the tests?...er..yeah that would explain why only lastok builds are green and lastrelease builds are not..so I guess I can declare success on Linux x86/ppc/sparc.. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Jul 2009 09:39:45 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] odbc errors > > Umm, I am confused. On my niagara box I don't have /usr/local/cm3, so exactly what should I be deleting? And why? > > On 28 Jul 2009, at 05:35, Jay K wrote: > > > odbc errors > > Tony, everyone, please read and then do like this: > > rm -rf /usr/local/cm3/pkg/*odbc* > rm -rf /usr/local/cm3/lib/*odbc* > cd root/cm3/m3-db > rm -rf odbc > cvs -z3 upd -dAP odbc > cd odbc > cm3 > cm3 -ship > > > cd ~/work/cm3-inst > find . | grep odbc | xargs rm > > > - Jay > From hosking at cs.purdue.edu Tue Jul 28 17:36:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 11:36:39 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: OK, deleting those now. On 28 Jul 2009, at 09:51, Jay K wrote: > > Whereever you have it installed. > > > The Modula-3 libodbc* was perhaps in conflict with other libodbc*. > There were at least warnings to this affect in some builds. > So it was renamed libm3odbc. However the old one isn't automatically > deleted. > I think we can always delete it -- assuming that cm3 libraries > aren't in the same directory as non-cm3 libraries but Olaf said not > to. > > > If you look at your Solaris Tinderbox test results you will see some > red I believe caused by this -- not deleting the old cm3 libodbc, > whereever it is. > > > I /think/ this failure to /build/ the tests is why the red or orange > status on Tinderbox instead of green. > But I'm not sure yet since I haven't gotten things to turn green yet. > Maybe we can only get green on the builds that don't run the > tests?...er..yeah that would explain why only lastok builds are > green and lastrelease builds are not..so I guess I can declare > success on Linux x86/ppc/sparc.. > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Jul 2009 09:39:45 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] odbc errors >> >> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, >> so exactly what should I be deleting? And why? >> >> On 28 Jul 2009, at 05:35, Jay K wrote: >> >> >> odbc errors >> >> Tony, everyone, please read and then do like this: >> >> rm -rf /usr/local/cm3/pkg/*odbc* >> rm -rf /usr/local/cm3/lib/*odbc* >> cd root/cm3/m3-db >> rm -rf odbc >> cvs -z3 upd -dAP odbc >> cd odbc >> cm3 >> cm3 -ship >> >> >> cd ~/work/cm3-inst >> find . | grep odbc | xargs rm >> >> >> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 28 17:44:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Jul 2009 11:44:50 -0400 Subject: [M3devel] odbc errors In-Reply-To: References: <7A733372-90A0-41FF-83CF-B9AD90E77B6B@cs.purdue.edu> Message-ID: I don't have any libodbc installed anywhere in my tinderbox builds. Must be something else going on. On 28 Jul 2009, at 11:36, Tony Hosking wrote: > OK, deleting those now. > > > On 28 Jul 2009, at 09:51, Jay K wrote: > >> >> Whereever you have it installed. >> >> >> The Modula-3 libodbc* was perhaps in conflict with other libodbc*. >> There were at least warnings to this affect in some builds. >> So it was renamed libm3odbc. However the old one isn't >> automatically deleted. >> I think we can always delete it -- assuming that cm3 libraries >> aren't in the same directory as non-cm3 libraries but Olaf said not >> to. >> >> >> If you look at your Solaris Tinderbox test results you will see >> some red I believe caused by this -- not deleting the old cm3 >> libodbc, whereever it is. >> >> >> I /think/ this failure to /build/ the tests is why the red or >> orange status on Tinderbox instead of green. >> But I'm not sure yet since I haven't gotten things to turn green yet. >> Maybe we can only get green on the builds that don't run the >> tests?...er..yeah that would explain why only lastok builds are >> green and lastrelease builds are not..so I guess I can declare >> success on Linux x86/ppc/sparc.. >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Jul 2009 09:39:45 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] odbc errors >>> >>> Umm, I am confused. On my niagara box I don't have /usr/local/cm3, >>> so exactly what should I be deleting? And why? >>> >>> On 28 Jul 2009, at 05:35, Jay K wrote: >>> >>> >>> odbc errors >>> >>> Tony, everyone, please read and then do like this: >>> >>> rm -rf /usr/local/cm3/pkg/*odbc* >>> rm -rf /usr/local/cm3/lib/*odbc* >>> cd root/cm3/m3-db >>> rm -rf odbc >>> cvs -z3 upd -dAP odbc >>> cd odbc >>> cm3 >>> cm3 -ship >>> >>> >>> cd ~/work/cm3-inst >>> find . | grep odbc | xargs rm >>> >>> >>> - Jay >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 28 22:45:27 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Jul 2009 16:45:27 -0400 Subject: [M3devel] new install on Windows Vista Message-ID: <4A6F2B27020000D70005D660@scires.com> Jay: You stated: >>> Jay K 07/28/09 12:24 AM >>> create \cm3\bin\cm3.cfg with the following exact contents: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) I am looking at the cm3.cfg you supplied with the d5.8.2.zip file. It has the following: INSTALL_ROOT = (path() & "/..") include(path() & "/config/NT386") Should it be HOST or NT386 ? Also, are the extra parenthesis in the first line needed? Thanks for your help. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 28 22:52:40 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Jul 2009 13:52:40 -0700 Subject: [M3devel] new install on Windows Vista In-Reply-To: <4A6F2B27020000D70005D660@scires.com> References: <4A6F2B27020000D70005D660@scires.com> Message-ID: Host or nt386 ok. Host is like target but is the running cm3, vs. what it is building, often the same thing and using host here makes them the same. (native build vs. cross build) Parens probably not needed right. If it works it is right. It won't appear to work but do the wrong thing. - Jay (phone) On Jul 28, 2009, at 1:45 PM, "Randy Coleburn" wrote: > Jay: > > You stated: > >>> Jay K 07/28/09 12:24 AM >>> > create \cm3\bin\cm3.cfg with the following exact contents: > INSTALL_ROOT = path() & "/.." > include(path() & "/config/" & HOST) > > I am looking at the cm3.cfg you supplied with the d5.8.2.zip file. > It has the following: > INSTALL_ROOT = (path() & "/..") > include(path() & "/config/NT386") > Should it be HOST or NT386 ? > Also, are the extra parenthesis in the first line needed? > > Thanks for your help. > --Randy From lists at darko.org Wed Jul 29 04:33:03 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 29 Jul 2009 04:33:03 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: Message-ID: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Yep, they work. Can you only use the version of VC that the compiler was built with? On 28/07/2009, at 2:07 PM, Jay K wrote: > > Try these that I just made? > > They were built with VC 9.0: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip > > I didn't test them (too much combinatorial explosion -- four things > to test!) > > and the readme from before: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt > > Olaf, there is a LOT more in the snaps directory than the snapshot- > index lists. > A lot. Also my archives contain more of the licenses, so many that I > put them in a subdirectory. > > > - Jay From jay.krell at cornell.edu Wed Jul 29 05:16:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 03:16:26 +0000 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> References: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Message-ID: The compiler isn't relevant. The libraries are. You might as well consider them as one indivisable unit, but they aren't quite. I don't yet fully understand the situation. Until/unless I/we do, we'll build a distribution per VC version. I should have renamed the below cm3-min-NT386-d5.8.2-vc90.zip or such but I was lazy and took advantage of there being no other 5.8.2 currently. Stay tuned (but don't hold your breath) for cm3-min-NT386-d5.8.2-vc80.zip and speak up as to which, IF ANY, of these is desired: cm3-min-NT386-d5.8.2-vc71.zip cm3-min-NT386-d5.8.2-vc70.zip cm3-min-NT386-d5.8.2-vc60.zip cm3-min-NT386-d5.8.2-vc50.zip cm3-min-NT386-d5.8.2-vc42.zip cm3-min-NT386-d5.8.2-vc41.zip cm3-min-NT386-d5.8.2-vc40.zip cm3-min-NT386-d5.8.2-vc20.zip (I haven't yet acquired the 32bit 1.0 version, but all the others have been tested surprisingly recently.) For that matter, among: Borland 5.5 (free "beer") Metrowerks 6, 7, 8 Digital Mars (free "beer") Open Watcom (free and open source) speak up as to which, IF ANY, are desired, and what to call the target. My experiment to call everything NT386 I've decided was a failure. I'll fix that in the next release. I386_NT_DIGITALMARS, I386_NT_WATCOM, I386_NT_CODEWARRIOR, I386_NT_BORLAND ? I386_NT_DMARS, I386_NT_WAT, I386_CW I386_NT_MWCW, I386_NT_BOR??? Borland seems to still be under development but current versions are expensive. I guess I should learn the jmpbuf size of all of those and see if everyone is close and if so use the largest of them. Then it's simply a matter of ensuring we use C wrappers enough (probably already do), and getting the compiler/linker switches reasonable on the config files. - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Date: Wed, 29 Jul 2009 04:33:03 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Dependency on msvcr80.dll > > Yep, they work. Can you only use the version of VC that the compiler > was built with? > > > On 28/07/2009, at 2:07 PM, Jay K wrote: > >> >> Try these that I just made? >> >> They were built with VC 9.0: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip >> >> I didn't test them (too much combinatorial explosion -- four things >> to test!) >> >> and the readme from before: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt >> >> Olaf, there is a LOT more in the snaps directory than the snapshot- >> index lists. >> A lot. Also my archives contain more of the licenses, so many that I >> put them in a subdirectory. >> >> >> - Jay > From lists at darko.org Wed Jul 29 08:24:29 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 29 Jul 2009 08:24:29 +0200 Subject: [M3devel] Dependency on msvcr80.dll In-Reply-To: References: <846FD8B1-3999-415B-BDA4-496C1640F8B9@darko.org> Message-ID: I think the latestest will suffice, since it sounds pretty easy to derive any other version from that one, and the latest VC version is freely available. The other compilers I wouldn't worry about since users probably don't exist, and if they do then they can use those products pretty easily with the VC command line tools. I use Metrowerks for instance (on the Mac) and have hacked a plugin that does most of what I want. Anyway, I'd hate to keep you from the much more interesting ARM_DARWIN :-) On 29/07/2009, at 5:16 AM, Jay K wrote: > > The compiler isn't relevant. > The libraries are. > You might as well consider them as one indivisable unit, but they > aren't quite. > I don't yet fully understand the situation. > Until/unless I/we do, we'll build a distribution per VC version. I > should have renamed the below > cm3-min-NT386-d5.8.2-vc90.zip or such but I was lazy and took > advantage of there being no other 5.8.2 currently. > > > Stay tuned (but don't hold your breath) for > cm3-min-NT386-d5.8.2-vc80.zip > > > and speak up as to which, IF ANY, of these is desired: > > cm3-min-NT386-d5.8.2-vc71.zip > cm3-min-NT386-d5.8.2-vc70.zip > cm3-min-NT386-d5.8.2-vc60.zip > cm3-min-NT386-d5.8.2-vc50.zip > cm3-min-NT386-d5.8.2-vc42.zip > cm3-min-NT386-d5.8.2-vc41.zip > cm3-min-NT386-d5.8.2-vc40.zip > cm3-min-NT386-d5.8.2-vc20.zip > (I haven't yet acquired the 32bit 1.0 version, but all the others > have been tested surprisingly recently.) > > > For that matter, among: > Borland 5.5 (free "beer") > Metrowerks 6, 7, 8 > Digital Mars (free "beer") > Open Watcom (free and open source) > > speak up as to which, IF ANY, are desired, and what to call the > target. > My experiment to call everything NT386 I've decided was a failure. > I'll fix that in the next release. > I386_NT_DIGITALMARS, I386_NT_WATCOM, I386_NT_CODEWARRIOR, > I386_NT_BORLAND ? > I386_NT_DMARS, I386_NT_WAT, I386_CW I386_NT_MWCW, I386_NT_BOR??? > Borland seems to still be under development but current versions are > expensive. > > I guess I should learn the jmpbuf size of all of those and see if > everyone is close and if so use the largest of them. Then it's > simply a matter of ensuring we use C wrappers enough (probably > already do), and getting the compiler/linker switches reasonable on > the config files. > > > - Jay > > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Wed, 29 Jul 2009 04:33:03 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Dependency on msvcr80.dll >> >> Yep, they work. Can you only use the version of VC that the compiler >> was built with? >> >> >> On 28/07/2009, at 2:07 PM, Jay K wrote: >> >>> >>> Try these that I just made? >>> >>> They were built with VC 9.0: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.2-symbols.zip >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.2-symbols.zip >>> >>> I didn't test them (too much combinatorial explosion -- four things >>> to test!) >>> >>> and the readme from before: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt >>> >>> Olaf, there is a LOT more in the snaps directory than the snapshot- >>> index lists. >>> A lot. Also my archives contain more of the licenses, so many that I >>> put them in a subdirectory. >>> >>> >>> - Jay >> From rcoleburn at scires.com Wed Jul 29 13:14:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 07:14:57 -0400 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) Message-ID: <4A6FF67C.1E75.00D7.1@scires.com> Update on NT386 build (Windows XP, Microsoft Visual C++ Express 2008), R.Coleburn ===================================================================== Here are the errors and warnings I am seeing currently in building the minimal installation: --- processing package "m3-libs\libm3" --- --- building in NT386 --- "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) 1 warning encountered Here is a list of all packages that I am building: m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-sys\windowsResources m3-libs\patternmatching m3-libs\sysutils m3-libs\unittest m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3staloneback m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3scanner m3-sys\m3tools m3-sys\m3cgcat m3-sys\m3cggen m3-sys\m3gdb m3-tools\m3bundle m3-sys\mklib m3-sys\fix_nl m3-sys\libdump m3-libs\arithmetic m3-libs\unittest-numeric m3-libs\bitvector m3-libs\digraph m3-libs\parseparams m3-libs\realgeometry m3-libs\set m3-libs\slisp m3-libs\sortedtableextras m3-libs\table-list m3-libs\tempfiles m3-libs\tcl m3-comm\tcp m3-sys\cm3ide m3-comm\udp m3-libs\libsio m3-libs\libbuf m3-libs\debug m3-libs\listfuncs m3-libs\embutils m3-libs\m3tk-misc m3-www\http m3-libs\binIO m3-libs\commandrw m3-comm\tapi m3-comm\serial m3-tools\m3tk m3-tools\mtex m3-tools\m3totex m3-tools\m3tohtml m3-tools\m3scan m3-tools\m3markup m3-tools\m3browser m3-tools\cmpdir m3-tools\cmpfp m3-tools\dirfp m3-tools\uniq m3-comm\netobj m3-comm\netobjd m3-comm\stubgen m3-comm\events m3-comm\rdwr m3-comm\sharedobj m3-comm\sharedobjgen m3-db\odbc m3-db\postgres95 m3-db\db m3-db\smalldb m3-db\stablegen m3-db\stable m3-ui\X11R4 m3-ui\ui m3-ui\PEX m3-ui\vbtkit m3-ui\cmvbt m3-ui\jvideo m3-ui\videovbt m3-www\web m3-www\proxy m3-ui\formsvbtpixmaps m3-ui\formsvbt m3-ui\formsview m3-ui\formsedit m3-ui\codeview m3-tools\cvsup\suplib m3-tools\cvsup\client m3-tools\cvsup\server m3-tools\cvsup\cvpasswd m3-ui\mg m3-ui\mgkit m3-ui\opengl m3-ui\anim3D m3-ui\zeus m3-ui\m3zume m3-obliq\synloc m3-obliq\synex m3-obliq\metasyn m3-obliq\obliqrt m3-obliq\obliqparse m3-obliq\obliqprint m3-obliq\obliq m3-obliq\obliqlibemb m3-obliq\obliqlibm3 m3-obliq\obliqlibui m3-obliq\obliqlibanim m3-obliq\obliqsrvstd m3-obliq\obliqsrvui m3-obliq\obliqbinmin m3-obliq\obliqbinstd m3-obliq\obliqbinui m3-obliq\obliqbinanim m3-obliq\obliqlib3D m3-obliq\visualobliq m3-obliq\vocgi m3-obliq\voquery m3-obliq\vorun m3-ui\webvbt m3-tools\recordheap m3-tools\rehearsecode m3-tools\replayheap m3-tools\showheap m3-tools\shownew m3-tools\showthread m3-ui\juno-2\juno-app\pkl-fonts m3-ui\juno-2\juno-machine m3-ui\juno-2\juno-compiler m3-ui\juno-2\juno-app m3-demo\cube m3-demo\calculator m3-demo\fisheye m3-demo\mentor caltech-parser\cit_common caltech-parser\m3tmplhack caltech-parser\cit_util caltech-parser\term m3-libs\deepcopy caltech-parser\paneman caltech-parser\paneman\kemacs caltech-parser\drawcontext caltech-parser\drawcontext\dcpane caltech-parser\drawcontext\kgv caltech-parser\hack caltech-parser\m3browserhack caltech-parser\parserlib\ktoklib caltech-parser\parserlib\klexlib caltech-parser\parserlib\kyacclib caltech-parser\parserlib\ktok caltech-parser\parserlib\klex caltech-parser\parserlib\kyacc caltech-parser\parserlib\kext caltech-parser\parserlib\parserlib caltech-parser\parserlib\parserlib\test m3-tools\pp m3-tools\kate m3-libs\sgml m3-www\deckscape m3-www\webscape m3-www\webcat m3-ui\bicycle m3-games\badbricks m3-games\columns m3-games\fours m3-games\maze m3-games\solitaire m3-games\tetris ---END-of-List--- Here are the errors and warnings I am seeing currently in building all the packages listed above: --- processing package "m3-sys\m3cc" --- --- building in NT386 --- ignoring ..\src\m3overrides _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MA KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap -disable-intl -di sable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages =m3cg -enable-targets=all -disable-dependency-tracking -disable-fixincludes -dis able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/cm3/Sandbox /cm3/m3-sys/m3cc/src/../NT386/_m3.log 'chmod' is not recognized as an internal or external command, operable program or batch file. 'sh' is not recognized as an internal or external command, operable program or batch file. "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake runtime error: exit 1: sh -ec ./_m3000.sh --procedure-- -line- -file--- exec -- m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args Fatal Error: package build failed --- processing package "m3-libs\libm3" --- --- building in NT386 --- "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) 1 warning encountered --- processing package "m3-sys\cm3" --- --- building in NT386 --- ignoring ..\src\m3overrides missing CM3_VERSION_NUMBER will read version file missing CM3_VERSION_TEXT will read version file missing CM3_LAST_CHANGED will read version file --- processing package "m3-sys\m3gdb" --- nothing attempts to build for this package --- processing package "m3-sys\mklib" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) (UNALIGNED) 1 warning encountered --- processing package "m3-db\postgres95" --- nothing attempts to build for this package --- processing package "m3-ui\X11R4" --- nothing attempts to build for this package --- processing package "m3-ui\PEX" --- nothing attempts to build for this package --- processing package "m3-tools\cvsup\suplib" --- --- processing package "m3-tools\cvsup\client" --- --- processing package "m3-tools\cvsup\server" --- --- processing package "m3-tools\cvsup\cvpasswd" --- nothing attempts to build for these packages --- processing package "m3-ui\anim3D" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Win_OpenGL_Base.m3 "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception is never raised: GraphicsBase.Failure "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: potentially unhandled exception: GraphicsBase.Failure 2 warnings encountered --- processing package "m3-obliq\obliqrt" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling ObValueCB.i3 "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) 1 warning encountered new source -> compiling ObValueCBProxy.i3 "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) 1 warning encountered new source -> compiling ObValueSO.m3 "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) 1 warning encountered new exporters -> recompiling ObValueCBProxy.i3 "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) 1 warning encountered --- processing package "caltech-parser\cit_common" --- --- building in NT386 --- ignoring ..\src\m3overrides unsupported m3_option value: "-X2 at -pg@" unsupported m3_option value: "-g" --- processing package "m3-libs\deepcopy" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling DeepCopy.m3 "..\src\DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory "..\src\DeepCopy.m3", line 61: warning: potentially unhandled exception: "..\src\DeepCopy.m3", line 97: warning: exception is never raised: 3 warnings encountered --- processing package "caltech-parser\parserlib\klexlib" --- --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RegExpTok.m3 "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered --- processing package "caltech-parser\parserlib\parserlib\test" --- --- building in NT386 --- ignoring ..\src\m3overrides C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed --- processing package "m3-tools\pp" --- nothing attempts to build for this package --- processing package "m3-tools\kate" --- --- building in NT386 --- KDESHARE not found; please define it! Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jul 29 13:30:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 07:30:25 -0400 Subject: [M3devel] prelim results on Vista Message-ID: <4A6FFA1C.1E75.00D7.1@scires.com> Jay: I tried building on Vista using the approach I outlined earlier, taking into account the config stuff you relayed to me. Thanks. I started with your d5.8.2 minimal binary install, fixed up the config stuff, and built the "min" packages, twice over. I succeeded in building the minimal installation (no fatal errors reported). Then, when trying to build everything, I ran into problems. See the list below. The first package to run into problems (aside from m3cc, which seems to be expected to fail on Windows) is m3-libs\sysutils. The errors stem from a missing Utypes interface. See below: new source -> compiling System.i3 "..\src\System.i3", line 40: unable to find interface (Utypes) "..\src\System.i3", line 37: symbol not exported (Utypes.pid_t) Any ideas on how to resolve? --Randy Coleburn ERROR LOG SUMMARY: ----------------- WARNING: Errors in package m3-sys\m3cc for -build WARNING: Errors in package m3-libs\sysutils for -build WARNING: Errors in package m3-libs\sysutils for -ship WARNING: Errors in package m3-sys\m3middle for -build WARNING: Errors in package m3-sys\m3objfile for -build WARNING: Errors in package m3-sys\m3linker for -build WARNING: Errors in package m3-sys\m3back for -build WARNING: Errors in package m3-sys\m3staloneback for -build WARNING: Errors in package m3-sys\m3front for -build WARNING: Errors in package m3-sys\m3quake for -build WARNING: Errors in package m3-sys\cm3 for -build WARNING: Errors in package m3-sys\m3tools for -build WARNING: Errors in package m3-sys\m3cgcat for -build WARNING: Errors in package m3-sys\m3cggen for -build WARNING: Errors in package m3-sys\mklib for -build WARNING: Errors in package m3-sys\libdump for -build WARNING: Errors in package m3-sys\cm3ide for -build WARNING: Errors in package m3-www\http for -build WARNING: Errors in package m3-tools\m3tohtml for -build WARNING: Errors in package m3-tools\m3browser for -build WARNING: Errors in package m3-www\proxy for -build WARNING: Errors in package m3-obliq\obliqrt for -build WARNING: Errors in package m3-obliq\obliqparse for -build WARNING: Errors in package m3-obliq\obliqprint for -build WARNING: Errors in package m3-obliq\obliq for -build WARNING: Errors in package m3-obliq\obliqlibemb for -build WARNING: Errors in package m3-obliq\obliqlibm3 for -build WARNING: Errors in package m3-obliq\obliqlibui for -build WARNING: Errors in package m3-obliq\obliqlibanim for -build WARNING: Errors in package m3-obliq\obliqsrvstd for -build WARNING: Errors in package m3-obliq\obliqsrvui for -build WARNING: Errors in package m3-obliq\obliqbinmin for -build WARNING: Errors in package m3-obliq\obliqbinstd for -build WARNING: Errors in package m3-obliq\obliqbinui for -build WARNING: Errors in package m3-obliq\obliqbinanim for -build WARNING: Errors in package m3-obliq\obliqlib3D for -build WARNING: Errors in package m3-obliq\visualobliq for -build WARNING: Errors in package m3-obliq\vocgi for -build WARNING: Errors in package m3-obliq\vorun for -build WARNING: Errors in package m3-ui\webvbt for -build WARNING: Errors in package m3-demo\mentor for -build WARNING: Errors in package caltech-parser\parserlib\parserlib\test for -build WARNING: Errors in package m3-libs\sgml for -build WARNING: Errors in package m3-www\deckscape for -build WARNING: Errors in package m3-www\webscape for -build WARNING: Errors in package m3-www\webcat for -build ---END-of-List--- ===END do-cm3=== C:\cm3\Sandbox\scripts\win>cd ..\..\m3-libs\sysutils C:\cm3\Sandbox\m3-libs\sysutils>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling System.i3 "..\src\System.i3", line 40: unable to find interface (Utypes) "..\src\System.i3", line 37: symbol not exported (Utypes.pid_t) 2 errors encountered new source -> compiling System.m3 "..\src\System.m3", line 27: imported interface contains errors (System) 1 error encountered new source -> compiling Confirmation.m3 "..\src\Confirmation.m3", line 5: imported interface contains errors (System) 1 error encountered new source -> compiling ConnectRdWr.m3 "..\src\ConnectRdWr.m3", line 6: imported interface contains errors (System) 1 error encountered new source -> compiling SystemWin32.m3 "..\src\WIN32\SystemWin32.m3", line 27: imported interface contains errors (System) 1 error encountered compilation failed => not building library "sysutils.lib" Fatal Error: package build failed CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 29 13:28:54 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 29 Jul 2009 04:28:54 -0700 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) In-Reply-To: <4A6FF67C.1E75.00D7.1@scires.com> References: <4A6FF67C.1E75.00D7.1@scires.com> Message-ID: Not bad! - Jay (phone) On Jul 29, 2009, at 4:14 AM, "Randy Coleburn" wrote: > Update on NT386 build (Windows XP, Microsoft Visual C++ Express > 2008), R.Coleburn > ===================================================================== > > Here are the errors and warnings I am seeing currently in building > the minimal installation: > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used > (CheckInt32) > 1 warning encountered > > > > Here is a list of all packages that I am building: > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-sys\windowsResources > m3-libs\patternmatching > m3-libs\sysutils > m3-libs\unittest > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3staloneback > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\m3scanner > m3-sys\m3tools > m3-sys\m3cgcat > m3-sys\m3cggen > m3-sys\m3gdb > m3-tools\m3bundle > m3-sys\mklib > m3-sys\fix_nl > m3-sys\libdump > m3-libs\arithmetic > m3-libs\unittest-numeric > m3-libs\bitvector > m3-libs\digraph > m3-libs\parseparams > m3-libs\realgeometry > m3-libs\set > m3-libs\slisp > m3-libs\sortedtableextras > m3-libs\table-list > m3-libs\tempfiles > m3-libs\tcl > m3-comm\tcp > m3-sys\cm3ide > m3-comm\udp > m3-libs\libsio > m3-libs\libbuf > m3-libs\debug > m3-libs\listfuncs > m3-libs\embutils > m3-libs\m3tk-misc > m3-www\http > m3-libs\binIO > m3-libs\commandrw > m3-comm\tapi > m3-comm\serial > m3-tools\m3tk > m3-tools\mtex > m3-tools\m3totex > m3-tools\m3tohtml > m3-tools\m3scan > m3-tools\m3markup > m3-tools\m3browser > m3-tools\cmpdir > m3-tools\cmpfp > m3-tools\dirfp > m3-tools\uniq > m3-comm\netobj > m3-comm\netobjd > m3-comm\stubgen > m3-comm\events > m3-comm\rdwr > m3-comm\sharedobj > m3-comm\sharedobjgen > m3-db\odbc > m3-db\postgres95 > m3-db\db > m3-db\smalldb > m3-db\stablegen > m3-db\stable > m3-ui\X11R4 > m3-ui\ui > m3-ui\PEX > m3-ui\vbtkit > m3-ui\cmvbt > m3-ui\jvideo > m3-ui\videovbt > m3-www\web > m3-www\proxy > m3-ui\formsvbtpixmaps > m3-ui\formsvbt > m3-ui\formsview > m3-ui\formsedit > m3-ui\codeview > m3-tools\cvsup\suplib > m3-tools\cvsup\client > m3-tools\cvsup\server > m3-tools\cvsup\cvpasswd > m3-ui\mg > m3-ui\mgkit > m3-ui\opengl > m3-ui\anim3D > m3-ui\zeus > m3-ui\m3zume > m3-obliq\synloc > m3-obliq\synex > m3-obliq\metasyn > m3-obliq\obliqrt > m3-obliq\obliqparse > m3-obliq\obliqprint > m3-obliq\obliq > m3-obliq\obliqlibemb > m3-obliq\obliqlibm3 > m3-obliq\obliqlibui > m3-obliq\obliqlibanim > m3-obliq\obliqsrvstd > m3-obliq\obliqsrvui > m3-obliq\obliqbinmin > m3-obliq\obliqbinstd > m3-obliq\obliqbinui > m3-obliq\obliqbinanim > m3-obliq\obliqlib3D > m3-obliq\visualobliq > m3-obliq\vocgi > m3-obliq\voquery > m3-obliq\vorun > m3-ui\webvbt > m3-tools\recordheap > m3-tools\rehearsecode > m3-tools\replayheap > m3-tools\showheap > m3-tools\shownew > m3-tools\showthread > m3-ui\juno-2\juno-app\pkl-fonts > m3-ui\juno-2\juno-machine > m3-ui\juno-2\juno-compiler > m3-ui\juno-2\juno-app > m3-demo\cube > m3-demo\calculator > m3-demo\fisheye > m3-demo\mentor > caltech-parser\cit_common > caltech-parser\m3tmplhack > caltech-parser\cit_util > caltech-parser\term > m3-libs\deepcopy > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\hack > caltech-parser\m3browserhack > caltech-parser\parserlib\ktoklib > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\kyacclib > caltech-parser\parserlib\ktok > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib > caltech-parser\parserlib\parserlib\test > m3-tools\pp > m3-tools\kate > m3-libs\sgml > m3-www\deckscape > m3-www\webscape > m3-www\webcat > m3-ui\bicycle > m3-games\badbricks > m3-games\columns > m3-games\fours > m3-games\maze > m3-games\solitaire > m3-games\tetris > ---END-of-List--- > > > > Here are the errors and warnings I am seeing currently in building > all the packages listed above: > > --- processing package "m3-sys\m3cc" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch > lex.yy.c' MA > KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap - > disable-intl -di > sable-libgomp -disable-libmudflap -disable-libssp -disable-nls - > enable-languages > =m3cg -enable-targets=all -disable-dependency-tracking -disable- > fixincludes -dis > able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/ > cm3/Sandbox > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > 'chmod' is not recognized as an internal or external command, > operable program or batch file. > 'sh' is not recognized as an internal or external command, > operable program or batch file. > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake > runtime error: > exit 1: sh -ec ./_m3000.sh > --procedure-- -line- -file--- > exec -- > m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc > \NT386\m3make.args > Fatal Error: package build failed > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used > (CheckInt32) > 1 warning encountered > > > --- processing package "m3-sys\cm3" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > --- processing package "m3-sys\m3gdb" --- > nothing attempts to build for this package > > > --- processing package "m3-sys\mklib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Main.m3 > "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) > (UNALIGNED) > 1 warning encountered > > > --- processing package "m3-db\postgres95" --- > nothing attempts to build for this package > > > --- processing package "m3-ui\X11R4" --- > nothing attempts to build for this package > > > --- processing package "m3-ui\PEX" --- > nothing attempts to build for this package > > > --- processing package "m3-tools\cvsup\suplib" --- > --- processing package "m3-tools\cvsup\client" --- > --- processing package "m3-tools\cvsup\server" --- > --- processing package "m3-tools\cvsup\cvpasswd" --- > nothing attempts to build for these packages > > > --- processing package "m3-ui\anim3D" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Win_OpenGL_Base.m3 > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception > is never raised: GraphicsBase.Failure > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: > potentially unhandled exception: GraphicsBase.Failure > 2 warnings encountered > > > --- processing package "m3-obliq\obliqrt" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling ObValueCB.i3 > "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueSO.m3 > "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) > 1 warning encountered > new exporters -> recompiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > > > --- processing package "caltech-parser\cit_common" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > unsupported m3_option value: "-X2 at -pg@" > unsupported m3_option value: "-g" > > > --- processing package "m3-libs\deepcopy" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling DeepCopy.m3 > "..\src\DeepCopy.m3", line 56: warning: potentially unhandled > exception: RTAllocator.OutOfMemory > "..\src\DeepCopy.m3", line 61: warning: potentially unhandled > exception: > "..\src\DeepCopy.m3", line 97: warning: exception is never raised: > > 3 warnings encountered > > > --- processing package "caltech-parser\parserlib\klexlib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling RegExpTok.m3 > "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled > exception: RTAllocator.OutOfMemory > 1 warning encountered > > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src > \Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime > error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok > \NT386\ktok ..\src\Calc.t -o CalcTok.i3 > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\NT386\m3make.args > Fatal Error: package build failed > > > --- processing package "m3-tools\pp" --- > nothing attempts to build for this package > > > --- processing package "m3-tools\kate" --- > --- building in NT386 --- > KDESHARE not found; please define it! > > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 29 14:06:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 14:06:46 +0200 Subject: [M3devel] Release engineering / OpenBSD status Message-ID: <20090729140646.2o9p3lcz4gc404s0@mail.elegosoft.com> Finally all relevant builds and tests have succeeded on OpenBSD in Hudson, too. See http://hudson.modula3.com:8080/view/I386_OPENBSD/ There are several package build/test failures though: http://hudson.modula3.com:8080/view/I386_OPENBSD/job/cm3-test-all-pkgs-I386_OPENBSD/lastBuild/testReport/ Some of these might be expected (no DB installation and other missing pre-requisites), but if anybody doesn't know how to spend his/her time, s/he might have a look at these (and fix them if possible). There are also 16 failures in m3-sys/m3tests: http://hudson.modula3.com:8080/view/I386_OPENBSD/job/cm3-test-m3tests-I386_OPENBSD/ In general everything looks much better than some days ago; the regression tests finally seem to stabilize. The failures currently visible in Hudson are all master/slave communication problems, and there's not one build red in the tinderbox :-) I think we should be able to build packages soon. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Jul 29 14:27:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 14:27:27 +0200 Subject: [M3devel] M3devel Digest, Vol 33, Issue 104 In-Reply-To: <28748.61011.qm@web56806.mail.re3.yahoo.com> References: <28748.61011.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090729142727.296t56l5u9wc0sg8@mail.elegosoft.com> Hi Peter, thanks for your encouragement. Regression builds look much better today, I think we may be able to have RC2 packages at the weekend. Though I'll have to attend to some other business then, too, like mawing the lawn in the garden ;-) I hope I'll find the time to work on your suggestions for the web presentation then, too. As for the Debian packages you've built, we should definitely link them on the release pages. But I doubt that I'll have time to test them. I trust that others will do that before the release though. Will your web server be able to manage several downloads, or should we copy them over to birch (which is usually heavily loaded most of the time), too? Olaf Quoting Peter Eiserloh : > Hi Olaf, > > I just wanted to say thank you! You have been doing a > great job. A compiler and development environment such > as CM3 is a very large software suite, and to coordinate > a software release is never an easy job. > > Sure the web pages can use some sprucing up, big deal! > Like you said, all the web pages are in the CVS repo, any > one with write access to the repo could change them. > > It may seem like there is a lot of complaining, and it is, > but what has everyone jazzed up at the moment (okay last > few months), is that shortly, all the work we have been > doing will be seeing a much larger audience, and we want > our favorite project to look its best. > > What we all should remember is that we all have real lives, > away from the computer and modula-3. None of us has enough > time to do _everything_ we want. > > BTW: I just wanted bring your attention to my latest build > of Debian packages for AMD64_LINUX on "lenny". I built it > today from cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. > > http://www.eiserloh.org/mirrors/modula3/ > > If you have a Debian-lenn-AM64 machine, could you try it > out. Maybe, even download the source package, and try > building it yourself. The source package should work with > any architecture supported by Debian. > > Please comment on any improvements I can make to these > debian packages. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > >> Date: Mon, 27 Jul 2009 22:49:26 +0200 >> From: Olaf Wagner >> Subject: Re: [M3devel] bad web pages > It will also be the >> last time that I coordinate a CM3 release. Everyone around >> me is already complaining :-( >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 19:42:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 17:42:22 +0000 Subject: [M3devel] unused warning isn't transitive Message-ID: TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; (* We need v to be inside a record. Otherwise, the language would allow a compiler to actually allocate more than the BITS 32 for a value of type Swap.Int32. *) VAR Int32RecVar : Int32Rec; VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); Compiler complains that CheckInt32 isn't used. It should also perhaps mention Int32RecVar therefore. - Jay From jay.krell at cornell.edu Wed Jul 29 20:18:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 18:18:30 +0000 Subject: [M3devel] update on NT386 build (Windows XP, VC 2008) In-Reply-To: References: <4A6FF67C.1E75.00D7.1@scires.com> Message-ID: (formatting possibly all messed up sorry) --- processing package "m3-sys\cm3" --- --- building in NT386 --- ignoring ..\src\m3overrides missing CM3_VERSION_NUMBER will read version file missing CM3_VERSION_TEXT will read version file missing CM3_LAST_CHANGED will read version file This is arguably a failing of your .cmd. The other .sh/.py/.cmd define these. Perhaps we should always do it in the m3makefile, nowhere else, and don't warn? Or maybe it is supposed to be fixed for the entire build? Or maybe Olaf just likes to write non portable .sh, in scripts, instead of in m3makefile? (where he can still write non portable .sh, but I have to port it, either way, difference is whether or not it gets written twice or four times, twice is Posix and Win32 in m3makefile, four times is Olaf's .sh, my .py, possibly maybe my .cmd, and your .cmd) Try the .py. Tell me what errors you get. Please. There are contradictory principles at work here: reduce dependencies don't duplicate work We are duplicating work. And I might continue to -- I might rewrite more of Olaf's .sh in .py. But my argument is that it is then more portable and the duplication can then be stopped. (Granted there are sticking points, like MIPS64_OPENBSD possibly and I386_MSDOS possibly, but sh's portability is also overstated, e.g. Solaris..) You can try my .cmd too, but I'd really like to know why the Python doesn't work for you. The .sh, .py, my .cmd, and indirectly the m3makefile read the scripts/version file. Which btw should maybe be at the root? Maybe. It depends on if you feel "scripts" are "official" or merely "convenience". And if "version" is "official" -- don't mix "official" with "convenience"? Not a big deal. Many of the warnings are in generated code, which is partly why I've long ignored them. Plus that I'm lazy. We can try putting in in the generated code. I just hope the compiler isn't a stickler then and complains that sometimes there is nothing to not warn about (like when you say but use it; geez, maybe my intent was, I may or may not use, just shut up either way?) I'll see what I can do, but none or almost none of this is Windows specific. Nobody seems to care much. That unaligned thing is different. - I thought it didn't warn on NT, just others. It possibly needs to be honored on all. - The Modula-3 language is difficient here in general. We need to be able to state alignment if we do want to "interoperate directly" with external data. Normally I say "write C wrappers" but this is a file format not a super cheap little in-memory struct. We almost need to be able to state alignments higher than we can today. I've seen stuff like: setjmp.h: gccism(alignment hgher than Modula-3 allows one to state) comment(less alignment is ok, but more is better) and Modula-3 uses less. Maybe it is yucky and not ANSI C but all the compilers have various extensions to finely control layout. Either we wrap everything up, or unpack from bytes, or copy those C features. Roughly speaking. I'll probably look into "unpack from bytes". Interfacing with the external world sometimes is ugly business and that's just tough; you can't change it. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Wed, 29 Jul 2009 04:28:54 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] update on NT386 build (Windows XP, VC 2008) > > Not bad! > > - Jay (phone) > > On Jul 29, 2009, at 4:14 AM, "Randy Coleburn"> wrote: > > > Update on NT386 build (Windows XP, Microsoft Visual C++ Express 2008), R.Coleburn > ===================================================================== > > > Here are the errors and warnings I am seeing currently in building the minimal installation: > > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) > 1 warning encountered > > > > > > > > Here is a list of all packages that I am building: > > > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-sys\windowsResources > m3-libs\patternmatching > m3-libs\sysutils > m3-libs\unittest > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3staloneback > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\m3scanner > m3-sys\m3tools > m3-sys\m3cgcat > m3-sys\m3cggen > m3-sys\m3gdb > m3-tools\m3bundle > m3-sys\mklib > m3-sys\fix_nl > m3-sys\libdump > m3-libs\arithmetic > m3-libs\unittest-numeric > m3-libs\bitvector > m3-libs\digraph > m3-libs\parseparams > m3-libs\realgeometry > m3-libs\set > m3-libs\slisp > m3-libs\sortedtableextras > m3-libs\table-list > m3-libs\tempfiles > m3-libs\tcl > m3-comm\tcp > m3-sys\cm3ide > m3-comm\udp > m3-libs\libsio > m3-libs\libbuf > m3-libs\debug > m3-libs\listfuncs > m3-libs\embutils > m3-libs\m3tk-misc > m3-www\http > m3-libs\binIO > m3-libs\commandrw > m3-comm\tapi > m3-comm\serial > m3-tools\m3tk > m3-tools\mtex > m3-tools\m3totex > m3-tools\m3tohtml > m3-tools\m3scan > m3-tools\m3markup > m3-tools\m3browser > m3-tools\cmpdir > m3-tools\cmpfp > m3-tools\dirfp > m3-tools\uniq > m3-comm\netobj > m3-comm\netobjd > m3-comm\stubgen > m3-comm\events > m3-comm\rdwr > m3-comm\sharedobj > m3-comm\sharedobjgen > m3-db\odbc > m3-db\postgres95 > m3-db\db > m3-db\smalldb > m3-db\stablegen > m3-db\stable > m3-ui\X11R4 > m3-ui\ui > m3-ui\PEX > m3-ui\vbtkit > m3-ui\cmvbt > m3-ui\jvideo > m3-ui\videovbt > m3-www\web > m3-www\proxy > m3-ui\formsvbtpixmaps > m3-ui\formsvbt > m3-ui\formsview > m3-ui\formsedit > m3-ui\codeview > m3-tools\cvsup\suplib > m3-tools\cvsup\client > m3-tools\cvsup\server > m3-tools\cvsup\cvpasswd > m3-ui\mg > m3-ui\mgkit > m3-ui\opengl > m3-ui\anim3D > m3-ui\zeus > m3-ui\m3zume > m3-obliq\synloc > m3-obliq\synex > m3-obliq\metasyn > m3-obliq\obliqrt > m3-obliq\obliqparse > m3-obliq\obliqprint > m3-obliq\obliq > m3-obliq\obliqlibemb > m3-obliq\obliqlibm3 > m3-obliq\obliqlibui > m3-obliq\obliqlibanim > m3-obliq\obliqsrvstd > m3-obliq\obliqsrvui > m3-obliq\obliqbinmin > m3-obliq\obliqbinstd > m3-obliq\obliqbinui > m3-obliq\obliqbinanim > m3-obliq\obliqlib3D > m3-obliq\visualobliq > m3-obliq\vocgi > m3-obliq\voquery > m3-obliq\vorun > m3-ui\webvbt > m3-tools\recordheap > m3-tools\rehearsecode > m3-tools\replayheap > m3-tools\showheap > m3-tools\shownew > m3-tools\showthread > m3-ui\juno-2\juno-app\pkl-fonts > m3-ui\juno-2\juno-machine > m3-ui\juno-2\juno-compiler > m3-ui\juno-2\juno-app > m3-demo\cube > m3-demo\calculator > m3-demo\fisheye > m3-demo\mentor > caltech-parser\cit_common > caltech-parser\m3tmplhack > caltech-parser\cit_util > caltech-parser\term > m3-libs\deepcopy > caltech-parser\paneman > caltech-parser\paneman\kemacs > caltech-parser\drawcontext > caltech-parser\drawcontext\dcpane > caltech-parser\drawcontext\kgv > caltech-parser\hack > caltech-parser\m3browserhack > caltech-parser\parserlib\ktoklib > caltech-parser\parserlib\klexlib > caltech-parser\parserlib\kyacclib > caltech-parser\parserlib\ktok > caltech-parser\parserlib\klex > caltech-parser\parserlib\kyacc > caltech-parser\parserlib\kext > caltech-parser\parserlib\parserlib > caltech-parser\parserlib\parserlib\test > m3-tools\pp > m3-tools\kate > m3-libs\sgml > m3-www\deckscape > m3-www\webscape > m3-www\webcat > m3-ui\bicycle > m3-games\badbricks > m3-games\columns > m3-games\fours > m3-games\maze > m3-games\solitaire > m3-games\tetris > ---END-of-List--- > > > > > > > > Here are the errors and warnings I am seeing currently in building all the packages listed above: > > > > --- processing package "m3-sys\m3cc" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MA > KEINFO=: ../gcc/configure -srcdir=../gcc -disable-bootstrap -disable-intl -di > sable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages > =m3cg -enable-targets=all -disable-dependency-tracking -disable-fixincludes -dis > able-libgcc -disable-decimal-float -disable-fixed-point | tee -a C:/cm3/Sandbox > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > 'chmod' is not recognized as an internal or external command, > operable program or batch file. > 'sh' is not recognized as an internal or external command, > operable program or batch file. > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line 385: quake runtime error: > exit 1: sh -ec ./_m3000.sh > --procedure-- -line- -file--- > exec -- > m3cc_Run 385 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > include_dir 514 C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args > Fatal Error: package build failed > > > > > --- processing package "m3-libs\libm3" --- > --- building in NT386 --- > "..\src\pickle\ver2\ConvertPacking.m3", line 170: warning: not used (CheckInt32) > 1 warning encountered > > > > > --- processing package "m3-sys\cm3" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > > > --- processing package "m3-sys\m3gdb" --- > nothing attempts to build for this package > > > > > --- processing package "m3-sys\mklib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Main.m3 > "..\src\Main.m3", line 28: warning: unrecognized pragma (ignored) (UNALIGNED) > 1 warning encountered > > > > > --- processing package "m3-db\postgres95" --- > nothing attempts to build for this package > > > > > --- processing package "m3-ui\X11R4" --- > nothing attempts to build for this package > > > > > --- processing package "m3-ui\PEX" --- > nothing attempts to build for this package > > > > > --- processing package "m3-tools\cvsup\suplib" --- > --- processing package "m3-tools\cvsup\client" --- > --- processing package "m3-tools\cvsup\server" --- > --- processing package "m3-tools\cvsup\cvpasswd" --- > nothing attempts to build for these packages > > > > > --- processing package "m3-ui\anim3D" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling Win_OpenGL_Base.m3 > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: warning: exception is never raised: GraphicsBase.Failure > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: warning: potentially unhandled exception: GraphicsBase.Failure > 2 warnings encountered > > > > > --- processing package "m3-obliq\obliqrt" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling ObValueCB.i3 > "..\NT386\ObValueCB.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > new source -> compiling ObValueSO.m3 > "..\NT386\ObValueSO.m3", line 12: warning: not used (AtomList) > 1 warning encountered > new exporters -> recompiling ObValueCBProxy.i3 > "..\NT386\ObValueCBProxy.i3", line 9: warning: not used (ObValueRep) > 1 warning encountered > > > > > --- processing package "caltech-parser\cit_common" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > unsupported m3_option value: "-X2 at -pg@" > unsupported m3_option value: "-g" > > > > > --- processing package "m3-libs\deepcopy" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling DeepCopy.m3 > "..\src\DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory > "..\src\DeepCopy.m3", line 61: warning: potentially unhandled exception: > "..\src\DeepCopy.m3", line 97: warning: exception is never raised: > 3 warnings encountered > > > > > --- processing package "caltech-parser\parserlib\klexlib" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > new source -> compiling RegExpTok.m3 > "..\NT386\RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory > 1 warning encountered > > > > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > ignoring ..\src\m3overrides > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > Fatal Error: package build failed > > > > > --- processing package "m3-tools\pp" --- > nothing attempts to build for this package > > > > > --- processing package "m3-tools\kate" --- > --- building in NT386 --- > KDESHARE not found; please define it! > > > > > Regards, > > Randy Coleburn > From wagner at elegosoft.com Wed Jul 29 20:34:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 20:34:25 +0200 Subject: [M3devel] m3cc build broken Message-ID: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> It looks as if the m3cc builds have broken after the last commit to the release branch: http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ error: ignoring ../src/m3overrides "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 292: quake runtime error: undefined variable: build_dir --procedure-- -line- -file--- m3cc_Run 292 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile include_dir 485 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile 4 /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args Fatal Error: package build failed What's going on there? Why is build_dir suddenly undefined? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 21:12:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 19:12:54 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> Message-ID: sorry, fixed now, agreed it is odd, I don't understand, undid my simple seeming change - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 20:34:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3cc build broken > > It looks as if the m3cc builds have broken after the last > commit to the release branch: > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > error: > ignoring ../src/m3overrides > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 292: quake runtime error: undefined variable: > build_dir > > --procedure-- -line- -file--- > m3cc_Run 292 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > include_dir 485 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > 4 > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > What's going on there? Why is build_dir suddenly undefined? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 29 21:23:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 21:23:39 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> Message-ID: <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Quoting Jay K : > sorry, fixed now, agreed it is odd, I don't understand, undid my > simple seeming change Never mind. The make-dist.sh script seems to be broken, too. Have a look at the end of http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. I guess I'll postpone package build again... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 29 21:58:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 19:58:04 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Message-ID: Whatever that was, can you run it again? Maybe with set -x? Which one? Searching for 'sed -e'... C:\dev2\cm3.2\scripts\boot-cm3-core.sh(30): sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-${CROSS_TARGET}/cm3cg\";" \ C:\dev2\cm3.2\scripts\find-packages.sh(23): grep /src/m3makefile | grep -v examples | grep -v _darcs | sed -e 's;/src/m3makefile$;;' | C:\dev2\cm3.2\scripts\find-packages.sh(24): sort | uniq | sed -e "s;^./;;" C:\dev2\cm3.2\scripts\find-src-dirs.sh(23): sed -e 's;/m3makefile$;;' -e 's;^;dir ;' C:\dev2\cm3.2\scripts\list-pkg-dirs.sh(39):for d in `listpkgs "$@" | sed -e "s;\$;/src;"`; do C:\dev2\cm3.2\scripts\list-pkg-dirs.sh(41):done | sed -e "s;^;${PREFIX};" C:\dev2\cm3.2\scripts\make-bin-dist-min.sh(107): sed -e ' C:\dev2\cm3.2\scripts\make-dist.sh(220): pw="`echo $p | sed -e 's;/;\\;g'`" C:\dev2\cm3.2\scripts\make-doc-dist.sh(48): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-script-dist.sh(39): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-all.sh(49): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-gnu.sh(51): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-std.sh(55): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-dist-sys.sh(57): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\make-src-update.sh(58): sed -e 's;^./;;'>> .tar-exclude C:\dev2\cm3.2\scripts\pkginfo.sh(94): a=`echo $a | sed -e "s;^${ROOT}/;;"` C:\dev2\cm3.2\scripts\pkginfo.sh(96): a=`echo $a | sed -e '/\//!s;^;/;'` C:\dev2\cm3.2\scripts\pkginfo.sh(99): done | sed -e "s;^;${ROOT}/;" C:\dev2\cm3.2\scripts\pkginfo.sh(101): cat "$PKGSDB" | sed -e "s;^;${ROOT}/;" C:\dev2\cm3.2\scripts\pkgmap.sh(221): echo "$1" | sed -e 's/&/&/g' -e 's//\>/g' C:\dev2\cm3.2\scripts\pkgmap.sh(234): pname=`echo $1 | sed -e 's;/;-;g'` C:\dev2\cm3.2\scripts\sysinfo.sh(241): CM3ROOT="`cygpath -w ${ROOT} | sed -e 's;\\\;\\\\\\\\;g'`" C:\dev2\cm3.2\scripts\regression\defs.sh(10):TESTHOSTNAME=${TESTHOSTNAME:-`hostname | sed -e 's/\..*//'`} C:\dev2\cm3.2\scripts\regression\defs.sh(311): R=`cygpath -w $1 | sed -e 's/\\\\/\\\\\\\\\\\\\\\\/g'` C:\dev2\cm3.2\scripts\regression\defs.sh(364): pat=`echo "${WS}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(370): pat=`echo "${RLOG}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(376): pat=`echo "${M3TOUT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(381): pat=`echo "${M3TERR}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(386): pat=`echo "${M3TERR}.extract" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(392): pat=`echo "${CM3_SNAPSHOT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\defs.sh(398): pat=`echo "${HTML_REPORT}" | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\tinderbox-build.sh(28):UNAME_R=`uname -r | sed -e 's/[^A-Za-z0-9_]/./g'` C:\dev2\cm3.2\scripts\regression\update_changelog.sh(16):WSPAT=`echo ${WS} | sed -e "s/${DS}/*/"` C:\dev2\cm3.2\scripts\regression\update_m3tests.sh(20): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_pkg_status.sh(20): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_snapshot_status.sh(27): sed -e "s/${FNPAT1}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | C:\dev2\cm3.2\scripts\regression\update_snapshot_status.sh(30): sed -e "s/${FNPAT2s}\([A-Za-z0-9_]*\)-.*${FNPATSUF}/\1/" | 37 occurrence(s) have been found. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 21:23:39 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cc build broken > > Quoting Jay K : > >> sorry, fixed now, agreed it is odd, I don't understand, undid my >> simple seeming change > > Never mind. The make-dist.sh script seems to be broken, too. > Have a look at the end of > http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. > > I guess I'll postpone package build again... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Jul 29 22:31:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Jul 2009 22:31:25 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> Message-ID: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Quoting Jay K : > Whatever that was, can you run it again? Maybe with set -x? I hope that works. Watch http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-lastok-build-AMD64_LINUX/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 00:16:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 22:16:56 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: making install.cmd ++ chmod 755 install.sh ++ echo 'REM ---BEGIN---' ++ echo '@echo off' ++ printf 'for %%%%p in (' ++ for p in '${PKGS}' +++ echo m3-demo/cube +++ sed -e 's;/;\;g' sed: -e expression #1, char 7: unterminated `s' command I'll rewrite this later. But wait, I'll give you a preview. install.cmd or setup.cmd shall be a constant file, checked in. Next to it shall be deposited file with a name and format largely of your own chosing. Maybe even with Unix newlines. Certainly forward slashes are fine. Obviously the file would just be a list of relative paths to cd to. I have a slight preference for setup.cmd over install.cmd because setup.exe is common on Windows and install.cmd is slightly ambiguous with Unix /usr/bin/install. Or call it m3ship.cmd or m3setup.cmd or whatever. The name doesn't matter. It will be a constant file, checked in. Pick a name, stake a claim -- checkin an empty file somewhere (scripts?), have your .sh copy it to where you want (the root of the relevant tree), put your text file next to it, I'll fill in the code later. The text file likely is in the same directory as the .cmd. The name can be constant and/or it can be based on the cmd name. foo.cmd => foo.cmd.txt or foo.txt. If you really don't want two files, then do this: Grab the stub .cmd. Append your data to it. But prepend each line with something special. And have "something special" start with "@rem". What the .cmd can do is run findstr on itself. e.g: set self=%~f0 like argv[] for /f %%a in ('findstr /b /c:"@rem special marker" %self%"') do call :F1 %%a goto :eof :F1 more code goto :eof : append your data here. Odds are high that this will actually be JScript code but that's ok, you can embed it in a .cmd file and the technique of finding a file next to self or data appended to self still apply (like people do with Perl with pl2bat). Oh sorry one more suggestion -- this setup could also be written in Modula-3. Not a bad idea. If it is, I recommend NOT static linking, but instead putting m3core.dll/libm3.dll next to it, as a special case, and not having them also be in the derived directory. That optimizes the size overall. It could also likely be quake. Also not a bad idea. I can never glean from the huge usage statement if there is a way to ask cm3 to just run some quake code, or if only prepend/append contents to whatever its normally will search for.. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 22:31:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cc build broken > > Quoting Jay K : > >> Whatever that was, can you run it again? Maybe with set -x? > > I hope that works. Watch > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-lastok-build-AMD64_LINUX/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 30 01:09:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Jul 2009 23:09:37 +0000 Subject: [M3devel] m3cc build broken In-Reply-To: <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: ---------------------------------------- > From: jay > To: wagner > CC: m3devel > Subject: RE: [M3devel] m3cc build broken > Date: Wed, 29 Jul 2009 22:16:56 +0000 > > > making install.cmd > ++ chmod 755 install.sh > ++ echo 'REM ---BEGIN---' > ++ echo '@echo off' > ++ printf 'for %%%%p in (' > ++ for p in '${PKGS}' > +++ echo m3-demo/cube > +++ sed -e 's;/;\;g' > sed: -e expression #1, char 7: unterminated `s' command > > Or just remove the sed and be done. cd accepts forward slashes on Windows. C:\>cd 1/2/3/4 C:\1\2\3\4> - Jay From wagner at elegosoft.com Thu Jul 30 01:25:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 01:25:48 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: References: <20090729203425.wq5rkzvdc8gc8o88@mail.elegosoft.com> <20090729212339.q3a9jlwty8oc0ksk@mail.elegosoft.com> <20090729223125.ngnaz1qyo40owgkc@mail.elegosoft.com> Message-ID: <20090730012548.0fsufbg62o0g8ow8@mail.elegosoft.com> Quoting Jay K : > > ---------------------------------------- >> From: jay >> To: wagner >> CC: m3devel >> Subject: RE: [M3devel] m3cc build broken >> Date: Wed, 29 Jul 2009 22:16:56 +0000 >> >> >> making install.cmd >> ++ chmod 755 install.sh >> ++ echo 'REM ---BEGIN---' >> ++ echo '@echo off' >> ++ printf 'for %%%%p in (' >> ++ for p in '${PKGS}' >> +++ echo m3-demo/cube >> +++ sed -e 's;/;\;g' >> sed: -e expression #1, char 7: unterminated `s' command > > Or just remove the sed and be done. > cd accepts forward slashes on Windows. Let's start with that. We can call it setup.cmd if you like. You can change the structure later. > C:\>cd 1/2/3/4 > > C:\1\2\3\4> I haven't found anything explaining the abstract method error. I'll just try to build everything manually first and see how far we get. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jul 30 01:36:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 29 Jul 2009 19:36:45 -0400 Subject: [M3devel] package groups question Message-ID: <4A70A456.1E75.00D7.1@scires.com> In reviewing PkgInfo.txt, I find that the "min" group has the following 3 members: m3-win\import-libs m3-libs\m3core m3-libs\libm3 Are these really all that is needed to build the "minimal" binary distribution? I also ran across group "front" whose members are: m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\mklib What is the purpose of this group? Just in case anyone is interested, my "do-cm3.cmd" script has the capability to enumerate the package groupings. Here is what I find: C:\cm3\Sandbox\scripts\win>do-cm3 showtags all ====== --------------------------------- do-cm3, v1.07, 7/29/2009, Randy Coleburn ====== --------------------------------- CM3 ARGS = showtags PkgInfo = C:\cm3\Sandbox\scripts\pkginfo.txt Pkg Tree = C:\cm3\Sandbox\ Group = all Enumerating group tags in "C:\cm3\Sandbox\scripts\pkginfo.txt" ... ... one moment please ... Group Tags: ---------- base core front min std gui comm caltech-parser m3gnudevtool devlib tool m3gdb math m3devtool obliq webdev database anim cvsup juno demo game ---END-of-LIST--- Enumerating group "all" ... one moment please ... Packages in Group="base": ------------------------------------------------------------------------------ import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3bundle mklib bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp tapi serial ---END-of-List--- Packages in Group="core": ------------------------------------------------------------------------------ import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3front m3quake cm3 m3scanner m3tools m3bundle mklib bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp ---END-of-List--- Packages in Group="front": ------------------------------------------------------------------------------ import-libs m3cc m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 mklib ---END-of-List--- Packages in Group="min": ------------------------------------------------------------------------------ import-libs m3core libm3 ---END-of-List--- Packages in Group="std": ------------------------------------------------------------------------------ import-libs m3core libm3 windowsResources patternmatching sysutils unittest m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle mklib fix_nl libdump arithmetic unittest-numeric bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl tcp cm3ide udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO commandrw tapi serial m3tk mtex m3totex m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db smalldb stablegen stable X11R4 ui PEX vbtkit cmvbt jvideo videovbt m3-www/web m3-www/proxy formsvbtpixmaps formsvbt formsview formsedit codeview cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd mg mgkit opengl anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap shownew showthread juno-2/juno-app/pkl-fonts juno-2/juno-machine juno-2/juno-compiler juno-2/juno-app cube calculator fisheye mentor ---END-of-List--- Packages in Group="gui": ------------------------------------------------------------------------------ import-libs tcp X11R4 ui vbtkit cmvbt jvideo videovbt formsvbtpixmaps formsvbt formsview formsedit opengl webvbt kate m3-ui/bicycle ---END-of-List--- Packages in Group="comm": ------------------------------------------------------------------------------ import-libs tcp udp m3tk-misc tapi serial m3tk netobj netobjd stubgen ---END-of-List--- Packages in Group="caltech-parser": ------------------------------------------------------------------------------ import-libs cit_common m3tmplhack cit_util term paneman paneman/kemacs drawcontext drawcontext/dcpane drawcontext/kgv hack m3browserhack parserlib/ktoklib parserlib/klexlib parserlib/kyacclib parserlib/ktok parserlib/klex parserlib/kyacc parserlib/kext parserlib/parserlib parserlib/parserlib/test ---END-of-List--- Packages in Group="m3gnudevtool": ------------------------------------------------------------------------------ m3cc m3gdb ---END-of-List--- Packages in Group="devlib": ------------------------------------------------------------------------------ windowsResources udp libsio libbuf debug listfuncs m3tk-misc binIO commandrw tapi serial m3tk m3scan m3markup events rdwr deepcopy sgml ---END-of-List--- Packages in Group="tool": ------------------------------------------------------------------------------ m3staloneback m3cgcat m3cggen fix_nl libdump cmpdir cmpfp dirfp uniq ---END-of-List--- Packages in Group="m3gdb": ------------------------------------------------------------------------------ m3gdb ---END-of-List--- Packages in Group="math": ------------------------------------------------------------------------------ arithmetic unittest-numeric ---END-of-List--- Packages in Group="m3devtool": ------------------------------------------------------------------------------ cm3ide m3totex m3tohtml m3browser netobj netobjd stubgen sharedobj sharedobjgen stablegen stable formsview formsedit recordheap rehearsecode replayheap showheap shownew showthread pp ---END-of-List--- Packages in Group="obliq": ------------------------------------------------------------------------------ embutils synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim obliqlib3D visualobliq vocgi voquery vorun ---END-of-List--- Packages in Group="webdev": ------------------------------------------------------------------------------ http m3-www/web m3-www/proxy webvbt deckscape webscape webcat ---END-of-List--- Packages in Group="database": ------------------------------------------------------------------------------ odbc postgres95 db smalldb ---END-of-List--- Packages in Group="anim": ------------------------------------------------------------------------------ codeview mg mgkit anim3D zeus m3zume mentor ---END-of-List--- Packages in Group="cvsup": ------------------------------------------------------------------------------ cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd ---END-of-List--- Packages in Group="juno": ------------------------------------------------------------------------------ juno-2/juno-app/pkl-fonts juno-2/juno-machine juno-2/juno-compiler juno-2/juno-app ---END-of-List--- Packages in Group="demo": ------------------------------------------------------------------------------ cube calculator fisheye ---END-of-List--- Packages in Group="game": ------------------------------------------------------------------------------ m3-games/badbricks m3-games/columns m3-games/fours m3-games/maze m3-games/solitaire m3-games/tetris ---END-of-List--- ===END do-cm3=== C:\cm3\Sandbox\scripts\win> Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 30 02:35:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 00:35:16 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A70A456.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> Message-ID: I'm only going to answer partially for now.. > Are these really all that is needed > to build the "minimal" binary distribution? It depends on what you mean. The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows). That's it. You don't need any packages at all. You don't need m3core/libm3. I setup tinderbox a few times recently. In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far). What that lets you do is build the whole system, from the bottom of the dependency tree and on up. HISTORICALLY there have been some wrinkles here. And it made pretty good sense, I guess, to draw another line. Whether or not that will happen again, unclear. The specific wrinkles were: - Old compiler could not compile a new libm3, if new targets had been added That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler - Old compiler cannot compile m3core or libm3 that uses LONGINT. Now, I have a suspicion that these issues are not extremely rare but just somewhat rare. All compilation systems written in themselves have a circularity. The compiler depends on the compiler. Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make. Let's imagine, crazy, that all the identifiers were changed to lowercase. If "just" change the compiler, well then, you can't build the compiler. You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form. I feel like I might be missing something though. In any case..what are the scenarios? - People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith. Give these people "std" or a bunch of binary packages. These people, in the extreme impatience form, would not even like Olaf's workspace packages. - People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3. Today you give these people cm3, cm3cg, and config files. But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does. The difference in DEC SRC is that quake was written in C, so the division was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose). - Various (infinite) in between situations such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases. Think of the C programmer who uses mainly just printf and malloc. Or the C++ programmer who also uses STL. If you give a programmer m3core/libm3, they are in a similar position. - Jay ________________________________ > Date: Wed, 29 Jul 2009 19:36:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] package groups question > > > > > > > > In reviewing PkgInfo.txt, I find that the "min" group has the following 3 members: > > > m3-win\import-libs > m3-libs\m3core > m3-libs\libm3 > > > > Are these really all that is needed to build the "minimal" binary distribution? > > > > I also ran across group "front" whose members are: > > m3-win\import-libs > m3-sys\m3cc > m3-libs\m3core > m3-libs\libm3 > m3-libs\sysutils > m3-sys\m3middle > m3-sys\m3objfile > m3-sys\m3linker > m3-sys\m3back > m3-sys\m3front > m3-sys\m3quake > m3-sys\cm3 > m3-sys\mklib > > > > What is the purpose of this group? > > > > Just in case anyone is interested, my "do-cm3.cmd" script has the capability to enumerate the package groupings. Here is what I find: > > > > > C:\cm3\Sandbox\scripts\win>do-cm3 showtags all > > ====== --------------------------------- > do-cm3, v1.07, 7/29/2009, Randy Coleburn > ====== --------------------------------- > > CM3 ARGS = showtags > PkgInfo = C:\cm3\Sandbox\scripts\pkginfo.txt > Pkg Tree = C:\cm3\Sandbox\ > Group = all > > Enumerating group tags in "C:\cm3\Sandbox\scripts\pkginfo.txt" ... > ... one moment please ... > > Group Tags: > ---------- > base > core > front > min > std > gui > comm > caltech-parser > m3gnudevtool > devlib > tool > m3gdb > math > m3devtool > obliq > webdev > database > anim > cvsup > juno > demo > game > ---END-of-LIST--- > > Enumerating group "all" ... one moment please ... > > Packages in Group="base": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > m3middle > m3quake > m3scanner > m3tools > m3bundle > mklib > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcp > tapi > serial > ---END-of-List--- > > > Packages in Group="core": > ------------------------------------------------------------------------------ > import-libs > m3cc > m3core > libm3 > patternmatching > sysutils > unittest > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > m3scanner > m3tools > m3bundle > mklib > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcp > ---END-of-List--- > > > Packages in Group="front": > ------------------------------------------------------------------------------ > import-libs > m3cc > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > mklib > ---END-of-List--- > > > Packages in Group="min": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > ---END-of-List--- > > > Packages in Group="std": > ------------------------------------------------------------------------------ > import-libs > m3core > libm3 > windowsResources > patternmatching > sysutils > unittest > m3middle > m3quake > m3scanner > m3tools > m3cgcat > m3cggen > m3gdb > m3bundle > mklib > fix_nl > libdump > arithmetic > unittest-numeric > bitvector > digraph > parseparams > realgeometry > set > slisp > sortedtableextras > table-list > tempfiles > tcl > tcp > cm3ide > udp > libsio > libbuf > debug > listfuncs > embutils > m3tk-misc > http > binIO > commandrw > tapi > serial > m3tk > mtex > m3totex > m3tohtml > m3scan > m3markup > m3browser > cmpdir > cmpfp > dirfp > uniq > netobj > netobjd > stubgen > events > rdwr > sharedobj > sharedobjgen > odbc > postgres95 > db > smalldb > stablegen > stable > X11R4 > ui > PEX > vbtkit > cmvbt > jvideo > videovbt > m3-www/web > m3-www/proxy > formsvbtpixmaps > formsvbt > formsview > formsedit > codeview > cvsup/suplib > cvsup/client > cvsup/server > cvsup/cvpasswd > mg > mgkit > opengl > anim3D > zeus > m3zume > synloc > synex > metasyn > obliqrt > obliqparse > obliqprint > obliq > obliqlibemb > obliqlibm3 > obliqlibui > obliqlibanim > obliqsrvstd > obliqsrvui > obliqbinmin > obliqbinstd > obliqbinui > obliqbinanim > visualobliq > vocgi > voquery > vorun > webvbt > recordheap > rehearsecode > replayheap > showheap > shownew > showthread > juno-2/juno-app/pkl-fonts > juno-2/juno-machine > juno-2/juno-compiler > juno-2/juno-app > cube > calculator > fisheye > mentor > ---END-of-List--- > > > Packages in Group="gui": > ------------------------------------------------------------------------------ > import-libs > tcp > X11R4 > ui > vbtkit > cmvbt > jvideo > videovbt > formsvbtpixmaps > formsvbt > formsview > formsedit > opengl > webvbt > kate > m3-ui/bicycle > ---END-of-List--- > > > Packages in Group="comm": > ------------------------------------------------------------------------------ > import-libs > tcp > udp > m3tk-misc > tapi > serial > m3tk > netobj > netobjd > stubgen > ---END-of-List--- > > > Packages in Group="caltech-parser": > ------------------------------------------------------------------------------ > import-libs > cit_common > m3tmplhack > cit_util > term > paneman > paneman/kemacs > drawcontext > drawcontext/dcpane > drawcontext/kgv > hack > m3browserhack > parserlib/ktoklib > parserlib/klexlib > parserlib/kyacclib > parserlib/ktok > parserlib/klex > parserlib/kyacc > parserlib/kext > parserlib/parserlib > parserlib/parserlib/test > ---END-of-List--- > > > Packages in Group="m3gnudevtool": > ------------------------------------------------------------------------------ > m3cc > m3gdb > ---END-of-List--- > > > Packages in Group="devlib": > ------------------------------------------------------------------------------ > windowsResources > udp > libsio > libbuf > debug > listfuncs > m3tk-misc > binIO > commandrw > tapi > serial > m3tk > m3scan > m3markup > events > rdwr > deepcopy > sgml > ---END-of-List--- > > > Packages in Group="tool": > ------------------------------------------------------------------------------ > m3staloneback > m3cgcat > m3cggen > fix_nl > libdump > cmpdir > cmpfp > dirfp > uniq > ---END-of-List--- > > > Packages in Group="m3gdb": > ------------------------------------------------------------------------------ > m3gdb > ---END-of-List--- > > > Packages in Group="math": > ------------------------------------------------------------------------------ > arithmetic > unittest-numeric > ---END-of-List--- > > > Packages in Group="m3devtool": > ------------------------------------------------------------------------------ > cm3ide > m3totex > m3tohtml > m3browser > netobj > netobjd > stubgen > sharedobj > sharedobjgen > stablegen > stable > formsview > formsedit > recordheap > rehearsecode > replayheap > showheap > shownew > showthread > pp > ---END-of-List--- > > > Packages in Group="obliq": > ------------------------------------------------------------------------------ > embutils > synloc > synex > metasyn > obliqrt > obliqparse > obliqprint > obliq > obliqlibemb > obliqlibm3 > obliqlibui > obliqlibanim > obliqsrvstd > obliqsrvui > obliqbinmin > obliqbinstd > obliqbinui > obliqbinanim > obliqlib3D > visualobliq > vocgi > voquery > vorun > ---END-of-List--- > > > Packages in Group="webdev": > ------------------------------------------------------------------------------ > http > m3-www/web > m3-www/proxy > webvbt > deckscape > webscape > webcat > ---END-of-List--- > > > Packages in Group="database": > ------------------------------------------------------------------------------ > odbc > postgres95 > db > smalldb > ---END-of-List--- > > > Packages in Group="anim": > ------------------------------------------------------------------------------ > codeview > mg > mgkit > anim3D > zeus > m3zume > mentor > ---END-of-List--- > > > Packages in Group="cvsup": > ------------------------------------------------------------------------------ > cvsup/suplib > cvsup/client > cvsup/server > cvsup/cvpasswd > ---END-of-List--- > > > Packages in Group="juno": > ------------------------------------------------------------------------------ > juno-2/juno-app/pkl-fonts > juno-2/juno-machine > juno-2/juno-compiler > juno-2/juno-app > ---END-of-List--- > > > Packages in Group="demo": > ------------------------------------------------------------------------------ > cube > calculator > fisheye > ---END-of-List--- > > > Packages in Group="game": > ------------------------------------------------------------------------------ > m3-games/badbricks > m3-games/columns > m3-games/fours > m3-games/maze > m3-games/solitaire > m3-games/tetris > ---END-of-List--- > > ===END do-cm3=== > > C:\cm3\Sandbox\scripts\win> > > > > > Regards, > > Randy Coleburn From rodney.m.bates at cox.net Thu Jul 30 03:57:42 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 29 Jul 2009 20:57:42 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: Message-ID: <4A70FE16.4080803@cox.net> Jay K wrote: > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record. Otherwise, the language would allow > a compiler to actually allocate more than the BITS 32 for a value of > type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > Transitive unusedness (boy, did that blow my email client spell checker's brains!) is a bigger issue than this example shows. There could be a large collection of identifiers that cyclically use each other, but no reference to the set from outside. For example, 35 mutually recursive, top-down parsing procedures that all call each other, but somebody forgot the base call to procedure "Program". Would we really want them all to come up unused, as well as everything declared inside any of them? It would take something like a strongly-connected graph components algorithm or such in the compiler. > > > - Jay > From rodney.m.bates at cox.net Thu Jul 30 03:48:36 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 29 Jul 2009 20:48:36 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: Message-ID: <4A70FBF4.9000806@cox.net> There is more wrong with this code than unused warnings. From 2.2.5 Packed types: "variables of type T that occur in records, objects, or arrays will occupy exactly n bits and be packed adjacent to the preceding field or element". (here, type T is BITS n FOR Base). The packed type has no effect when variables of T are not so enclosed. And the Int32Rec is nowhere enclosed in a record, object, or array. Perhaps the BITS 32 FOR should be moved inside the record and applied to the type of field v? Jay K wrote: > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record. Otherwise, the language would allow > a compiler to actually allocate more than the BITS 32 for a value of > type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > > > - Jay > From wagner at elegosoft.com Thu Jul 30 08:40:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 08:40:13 +0200 Subject: [M3devel] C compilation on Windows fails Message-ID: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Trying the first builds on our new Windows VM (still without Hudson), the first stop is: new source -> compiling hand.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\Common\\hand.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\Common\hand.c new source -> compiling dtoa.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\little-endian\\dtoa.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\little-endian\dtoa.c new source -> compiling libgcc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\libgcc\\libgcc.c compile_c => 1073742133 C compiler failed compiling: ..\src\Csupport\libgcc\libgcc.c new source -> compiling RTLinkerC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\common\\RTLinkerC.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\common\RTLinkerC.c new source -> compiling RTOSc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\WIN32\\RTOSc.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\ex_frame\\RTStackC.c compile_c => 1073742133 C compiler failed compiling: ..\src\runtime\ex_frame\RTStackC.c new source -> compiling ThreadWin32C.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WIN32\\ThreadWin32C.c compile_c => 1073742133 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c compile_c => 1073742133 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c compile_c => 1073742133 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CerrnoC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CerrnoC.c compile_c => 1073742133 C compiler failed compiling: ..\src\C\Common\CerrnoC.c new source -> compiling CstdioC.c cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c compile_c => 1073742133 C compiler failed compiling: ..\src\C\Common\CstdioC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling ThreadInternal.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** Why does the compiler always return 1073742133? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 09:26:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 07:26:42 +0000 Subject: [M3devel] unused warning isn't transitive In-Reply-To: <4A70FBF4.9000806@cox.net> References: <4A70FBF4.9000806@cox.net> Message-ID: 1) I was guessing inappropriately when I added BITS 32. I'll remove it. 2) I understand the need to have exactly sized types, certainly. I don't understand Modula-3's features here. - Jay ---------------------------------------- > Date: Wed, 29 Jul 2009 20:48:36 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] unused warning isn't transitive > > There is more wrong with this code than unused warnings. > From 2.2.5 Packed types: "variables of type T that occur in > records, objects, or arrays will occupy exactly n bits and be > packed adjacent to the preceding field or element". > (here, type T is BITS n FOR Base). > > The packed type has no effect when variables of T are not > so enclosed. And the Int32Rec is nowhere enclosed in a > record, object, or array. Perhaps the BITS 32 FOR should be > moved inside the record and applied to the type of field v? > > > Jay K wrote: >> TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; >> (* We need v to be inside a record. Otherwise, the language would allow >> a compiler to actually allocate more than the BITS 32 for a value of >> type Swap.Int32. >> *) >> VAR Int32RecVar : Int32Rec; >> VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); >> >> >> Compiler complains that CheckInt32 isn't used. >> It should also perhaps mention Int32RecVar therefore. >> >> >> - Jay >> > From jay.krell at cornell.edu Thu Jul 30 09:32:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 07:32:51 +0000 Subject: [M3devel] C compilation on Windows fails In-Reply-To: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> References: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Message-ID: Peel the onion. cl Should print a banner and very short usage. If that works: echo.> foo.c cl -c foo.c echo %errorlevel% If that works: echo int main(){return 0;}> foo.c cl foo.c echo %errorlevel% .\foo.exe If that works, take a big step: cd wherever\m3-libs\m3core\NT386 cl -nologo -c ..\src\Csupport\Common\hand.c If that fails for lack of -I switches, add them as necessary. Add back the other switches. They are all reliable. - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 08:40:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] C compilation on Windows fails > > Trying the first builds on our new Windows VM (still without Hudson), > the first stop is: > > new source -> compiling hand.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\Common\\hand.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\Common\hand.c > new source -> compiling dtoa.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\little-endian\\dtoa.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\little-endian\dtoa.c > new source -> compiling libgcc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\Csupport\\libgcc\\libgcc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\Csupport\libgcc\libgcc.c > new source -> compiling RTLinkerC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\common\\RTLinkerC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\common\RTLinkerC.c > new source -> compiling RTOSc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\WIN32\\RTOSc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c > new source -> compiling RTStackC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\ex_frame\\RTStackC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\runtime\ex_frame\RTStackC.c > new source -> compiling ThreadWin32C.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WIN32\\ThreadWin32C.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c > new source -> compiling WinNTc.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\win32\WinNTc.c > new source -> compiling WinUserC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\win32\WinUserC.c > new source -> compiling CerrnoC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CerrnoC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\C\Common\CerrnoC.c > new source -> compiling CstdioC.c > cl -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src/Csupport/Common > -I../src/Csupport/little-endian -I../src/Csupport/libgcc > -I../src/runtime/common -I../src/runtime/WIN32 > -I../src/runtime/ex_frame -I../src/thread/WIN32 -I../src/win32 > -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c > compile_c => 1073742133 > C compiler failed compiling: ..\src\C\Common\CstdioC.c > new exporters -> recompiling RTHooks.i3 > new exporters -> recompiling RTAllocCnts.i3 > new exporters -> recompiling RTHeapRep.i3 > new exporters -> recompiling RTCollectorSRC.i3 > new exporters -> recompiling RTWeakRef.i3 > new exporters -> recompiling RTException.i3 > new exporters -> recompiling RTModule.i3 > new exporters -> recompiling RTProcedureSRC.i3 > new exporters -> recompiling RTTypeSRC.i3 > new exporters -> recompiling RTOS.i3 > new exporters -> recompiling Thread.i3 > new exporters -> recompiling Scheduler.i3 > new exporters -> recompiling ThreadF.i3 > new exporters -> recompiling ThreadInternal.i3 > new exporters -> recompiling Tick.i3 > new exporters -> recompiling Date.i3 > new exporters -> recompiling Text.i3 > compilation failed => not building library "m3core.lib" > Fatal Error: package build failed > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > Why does the compiler always return 1073742133? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 30 09:54:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 09:54:22 +0200 Subject: [M3devel] C compilation on Windows fails In-Reply-To: References: <20090730084013.gjvv46mt0co8ggcw@mail.elegosoft.com> Message-ID: <20090730095422.57hmgjn5ycocssog@mail.elegosoft.com> Quoting Jay K : > Peel the onion. > cl > > Should print a banner and very short usage. > If that works: > > echo.> foo.c > cl -c foo.c > echo %errorlevel% > > If that works: > > echo int main(){return 0;}> foo.c > cl foo.c > echo %errorlevel% > .\foo.exe > > If that works, take a big step: > > cd wherever\m3-libs\m3core\NT386 > cl -nologo -c ..\src\Csupport\Common\hand.c > If that fails for lack of -I switches, add them as necessary. > Add back the other switches. They are all reliable. OK. Will try that tonight (in about 10 hours -- just arrived at work)... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 10:12:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 08:12:21 +0000 Subject: [M3devel] NetBSD 5.0? Message-ID: I assume nobody cares if support for NetBSD prior to 5.0 is dropped? 5.0 was released April 29, 2009 and supports $ORIGIN. This doesn't mean much anyway, in that supporting additional systems is usually not difficult. - Jay From rodney.m.bates at cox.net Thu Jul 30 15:23:03 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 30 Jul 2009 08:23:03 -0500 Subject: [M3devel] unused warning isn't transitive In-Reply-To: References: <4A70FBF4.9000806@cox.net> Message-ID: <4A719EB7.4010500@cox.net> Jay K wrote: > 1) I was guessing inappropriately when I added BITS 32. I'll remove it. > I didn't realize you had recently added this. Wasn't there something similar from earlier? > 2) I understand the need to have exactly sized types, certainly. I don't understand Modula-3's features here. > Modula-3 packed types are often not well understood. The language is more-abstract/higher-level than many languages, and this is unfamiliar. Some things that seem to be frequently missed: 1) Packed types have no effect on the set of values representable. That comes strictly from the base type, which is the abstract part. Packed types can only force the compiler neither to allocate padding nor more bits than needed by the value set of the base type. 2) Packed types have an effect only when used as the type of a field of a record or object or as the type of elements of an array. Declaring a whole variable of a packed type doesn't do anything different from declaring it to have the base type. (Except, there are some losses to assignability, e.g., you can't directly assign between two different packed types that have the same base type.) > > > - Jay > > > > > ---------------------------------------- > >> Date: Wed, 29 Jul 2009 20:48:36 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] unused warning isn't transitive >> >> There is more wrong with this code than unused warnings. >> From 2.2.5 Packed types: "variables of type T that occur in >> records, objects, or arrays will occupy exactly n bits and be >> packed adjacent to the preceding field or element". >> (here, type T is BITS n FOR Base). >> >> The packed type has no effect when variables of T are not >> so enclosed. And the Int32Rec is nowhere enclosed in a >> record, object, or array. Perhaps the BITS 32 FOR should be >> moved inside the record and applied to the type of field v? >> >> >> Jay K wrote: >> >>> TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; >>> (* We need v to be inside a record. Otherwise, the language would allow >>> a compiler to actually allocate more than the BITS 32 for a value of >>> type Swap.Int32. >>> *) >>> VAR Int32RecVar : Int32Rec; >>> VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - ADR(Int32RecVar.v); >>> >>> >>> Compiler complains that CheckInt32 isn't used. >>> It should also perhaps mention Int32RecVar therefore. >>> >>> >>> - Jay >>> >>> From eiserlohpp at yahoo.com Thu Jul 30 18:15:42 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 30 Jul 2009 09:15:42 -0700 (PDT) Subject: [M3devel] m3cc build broken In-Reply-To: Message-ID: <939290.13563.qm@web56801.mail.re3.yahoo.com> The following does look broken. Remember the backslash is an escape character. So you are escaping the ";" delimitor. You need to escape the backslash. > +++ sed -e 's;/;\;g' > sed: -e expression #1, char 7: unterminated `s' command Try: sed -e 's;/;\\;g' +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Thu Jul 30 18:30:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 18:30:50 +0200 Subject: [M3devel] cl on windows Message-ID: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> kind of consistent user interface: elego at wagner ~/work/cm3 $ type cl cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) elego at wagner ~/work/cm3 $ cl elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -version elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -help elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl /help elego at wagner ~/work/cm3 $ echo $? 53 Can it do something else? Visual Studio Setup completely broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 18:33:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 18:33:29 +0200 Subject: [M3devel] m3cc build broken In-Reply-To: <939290.13563.qm@web56801.mail.re3.yahoo.com> References: <939290.13563.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090730183329.mpy2y22tcwo008cw@mail.elegosoft.com> Quoting Peter Eiserloh : > The following does look broken. Remember the backslash is > an escape character. So you are escaping the ";" delimitor. > You need to escape the backslash. > >> +++ sed -e 's;/;\;g' >> sed: -e expression #1, char 7: unterminated `s' command > > Try: > sed -e 's;/;\\;g' It was escaped in the source, but the `fix' to remove $() broke it again: echo 'REM ---BEGIN---' echo '@echo off' printf 'for %%%%p in (' for p in ${PKGS}; do - pw=$(echo $p | sed -e 's;/;\\;g') + pw="`echo $p | sed -e 's;/;\\;g'`" printf "%s; " ${pw} done echo ') do call :ShipIt %%p' It was even tested before. Now it's completely removed, as Jay says forward slashes will just work everywhere. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Thu Jul 30 18:33:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 30 Jul 2009 09:33:58 -0700 (PDT) Subject: [M3devel] Web page experimental colors In-Reply-To: Message-ID: <442486.20009.qm@web56806.mail.re3.yahoo.com> Hi Olaf, www.eiserloh.org is my personal machine, on which I do most of my personal stuff. I have been putting things on its web server so other people can get to those public items I have made. I will probably have to get an account on birch or something. Speaking of debian packages, I am building a virtual machine for ARM_LINUX using qemu. Currently installing Debian Lenny in it. Inside which I will build set of CM3 debian packages for ARM. Following that: PPC_LINUX. Now if I could only get my "nslu2" up and running again. :-) Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Wed, 7/29/09, m3devel-request at elegosoft.com wrote: > From: m3devel-request at elegosoft.com > Subject: M3devel Digest, Vol 33, Issue 113 > To: m3devel at elegosoft.com > Date: Wednesday, July 29, 2009, 12:23 PM > Send M3devel mailing list submissions > to > ??? m3devel at elegosoft.com > > To subscribe or unsubscribe via the World Wide Web, visit > ??? https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > or, via email, send a message with subject or body 'help' > to > ??? m3devel-request at elegosoft.com > > You can reach the person managing the list at > ??? m3devel-owner at elegosoft.com > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of M3devel digest..." > > > Today's Topics: > > ???1. Re: M3devel Digest, Vol 33, Issue 104 > (Olaf Wagner) > ???2. unused warning isn't transitive (Jay > K) > ???3. Re: update on NT386 build (Windows XP, > VC 2008) (Jay K) > ???4. m3cc build broken (Olaf Wagner) > ???5. Re: m3cc build broken (Jay K) > ???6. Re: m3cc build broken (Olaf Wagner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Jul 2009 14:27:27 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 104 > To: m3devel at elegosoft.com > Message-ID: <20090729142727.296t56l5u9wc0sg8 at mail.elegosoft.com> > Content-Type: text/plain;??? > charset=UTF-8;??? > DelSp="Yes";??? format="flowed" > > Hi Peter, > > thanks for your encouragement. > Regression builds look much better today, I think we may > be > able to have RC2 packages at the weekend. Though I'll have > to attend > to some other business then, too, like mawing the lawn in > the > garden ;-) > > I hope I'll find the time to work on your suggestions for > the > web presentation then, too. > > As for the Debian packages you've built, we should > definitely > link them on the release pages. But I doubt that I'll have > time > to test them. I trust that others will do that before the > release > though. Will your web server be able to manage several > downloads, > or should we copy them over to birch (which is usually > heavily > loaded most of the time), too? > > Olaf > > Quoting Peter Eiserloh : > > > Hi Olaf, > > > > I just wanted to say thank you!? You have been > doing a > > great job.???A compiler and development > environment such > > as CM3 is a very large software suite, and to > coordinate > > a software release is never an easy job. > > > > Sure the web pages can use some sprucing up, big > deal! > > Like you said, all the web pages are in the CVS repo, > any > > one with write access to the repo could change them. > > > > It may seem like there is a lot of complaining, and it > is, > > but what has everyone jazzed up at the moment (okay > last > > few months), is that shortly, all the work we have > been > > doing will be seeing a much larger audience, and we > want > > our favorite project to look its best. > > > > What we all should remember is that we all have real > lives, > > away from the computer and modula-3.? None of us > has enough > > time to do _everything_ we want. > > > > BTW: I just wanted bring your attention to my latest > build > > of Debian packages for AMD64_LINUX on "lenny".? I > built it > > today from > cm3-src-all-d5.8.2-2009-07-27-01-37-49.tgz. > > > >? ? http://www.eiserloh.org/mirrors/modula3/ > > > > If you have a Debian-lenn-AM64 machine, could you try > it > > out.? Maybe, even download the source package, > and try > > building it yourself.? The source package should > work with > > any architecture supported by Debian. > > > > Please comment on any improvements I can make to > these > > debian packages. > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? | > > > +--------------------------------------------------------+ > > > >> Date: Mon, 27 Jul 2009 22:49:26 +0200 > >> From: Olaf Wagner > >> Subject: Re: [M3devel] bad web pages > >? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? It will also be the > >> last time that I coordinate a CM3 release. > Everyone around > >> me is already complaining :-( > >> > >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Jul 2009 17:42:22 +0000 > From: Jay K > Subject: [M3devel] unused warning isn't transitive > To: m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > TYPE Int32Rec = BITS 32 FOR RECORD v : Swap.Int32 END; > (* We need v to be inside a record.? Otherwise, the > language would allow > ???a compiler to actually allocate more than > the BITS 32 for a value of > ???type Swap.Int32. > *) > VAR Int32RecVar : Int32Rec; > VAR CheckInt32 : [ 0 .. 0 ] := ADR(Int32RecVar) - > ADR(Int32RecVar.v); > > > Compiler complains that CheckInt32 isn't used. > It should also perhaps mention Int32RecVar therefore. > > > - Jay > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jul 2009 18:18:30 +0000 > From: Jay K > Subject: Re: [M3devel] update on NT386 build (Windows XP, > VC 2008) > To: > Cc: m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > (formatting possibly all messed up sorry) > > > --- processing package "m3-sys\cm3" --- --- building in > NT386 --- ignoring ..\src\m3overrides > missing CM3_VERSION_NUMBER will read version file > missing CM3_VERSION_TEXT will read version file > missing CM3_LAST_CHANGED will read version file > > > This is arguably a failing of your .cmd. The other > .sh/.py/.cmd define these. > Perhaps we should always do it in the m3makefile, nowhere > else, and don't warn? > Or maybe it is supposed to be fixed for the entire build? > Or maybe Olaf just likes to write non portable .sh, in > scripts, instead of in m3makefile? > (where he can still write non portable .sh, but I have to > port it, either way, difference is whether or not it gets > written twice or four times, > twice is Posix and Win32 in m3makefile, four times is > Olaf's .sh, my .py, possibly maybe my .cmd, and your .cmd) > > > Try the .py. Tell me what errors you get. Please. > > > There are contradictory principles at work here: > ? reduce dependencies > ? don't duplicate work > > > We are duplicating work. And I might continue to -- I might > rewrite more of Olaf's .sh in .py. But my argument is that > it is > then more portable and the duplication can then be stopped. > (Granted there are sticking points, like MIPS64_OPENBSD > possibly and > I386_MSDOS possibly, but sh's portability is also > overstated, e.g. Solaris..) > > > You can try my .cmd too, but I'd really like to know why > the Python doesn't work for you. > The .sh, .py, my .cmd, and indirectly the m3makefile read > the scripts/version file. > Which btw should maybe be at the root? Maybe. It depends on > if you feel "scripts" are "official" or merely > "convenience". > And if "version" is "official" -- don't mix "official" with > "convenience"? Not a big deal. > > > Many of the warnings are in generated code, which is partly > why I've long ignored them. Plus that I'm lazy. > We can try putting in? in the generated code. I just > hope the compiler isn't a stickler > then and complains that sometimes there is nothing to not > warn about (like when you say? but use it; > geez, maybe my intent was, I may or may not use, just shut > up either way?) > > > I'll see what I can do, but none or almost none of this is > Windows specific. Nobody seems to care much. > > > That unaligned thing is different. - I thought it didn't > warn on NT, just others. > It possibly needs to be honored on all. > ? - The Modula-3 language is difficient here in > general. > We need to be able to state alignment if we do want to > "interoperate directly" with external data. > Normally I say "write C wrappers" but this is a file format > not a super cheap little in-memory struct. > We almost need to be able to state alignments higher than > we can today. > > > I've seen stuff like: > setjmp.h: > ? gccism(alignment hgher than Modula-3 allows one to > state) > ? comment(less alignment is ok, but more is better) > > > and Modula-3 uses less. Maybe it is yucky and not ANSI C > but all the compilers have various extensions to finely > control layout. > Either we wrap everything up, or unpack from bytes, or copy > those C features. Roughly speaking. > I'll probably look into "unpack from bytes". > Interfacing with the external world sometimes is ugly > business and that's just tough; you can't change it. > > > - Jay > > > > > > > > > > > > ________________________________ > > From: jay.krell at cornell.edu > > To: rcoleburn at scires.com > > Date: Wed, 29 Jul 2009 04:28:54 -0700 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] update on NT386 build (Windows > XP, VC 2008) > > > > Not bad! > > > > - Jay (phone) > > > > On Jul 29, 2009, at 4:14 AM, "Randy Coleburn"> > wrote: > > > > > > Update on NT386 build (Windows XP, Microsoft Visual > C++ Express 2008), R.Coleburn > > > ===================================================================== > > > > > > Here are the errors and warnings I am seeing currently > in building the minimal installation: > > > > > > > > --- processing package "m3-libs\libm3" --- > > --- building in NT386 --- > > "..\src\pickle\ver2\ConvertPacking.m3", line 170: > warning: not used (CheckInt32) > > 1 warning encountered > > > > > > > > > > > > > > > > Here is a list of all packages that I am building: > > > > > > > > m3-win\import-libs > > m3-sys\m3cc > > m3-libs\m3core > > m3-libs\libm3 > > m3-sys\windowsResources > > m3-libs\patternmatching > > m3-libs\sysutils > > m3-libs\unittest > > m3-sys\m3middle > > m3-sys\m3objfile > > m3-sys\m3linker > > m3-sys\m3back > > m3-sys\m3staloneback > > m3-sys\m3front > > m3-sys\m3quake > > m3-sys\cm3 > > m3-sys\m3scanner > > m3-sys\m3tools > > m3-sys\m3cgcat > > m3-sys\m3cggen > > m3-sys\m3gdb > > m3-tools\m3bundle > > m3-sys\mklib > > m3-sys\fix_nl > > m3-sys\libdump > > m3-libs\arithmetic > > m3-libs\unittest-numeric > > m3-libs\bitvector > > m3-libs\digraph > > m3-libs\parseparams > > m3-libs\realgeometry > > m3-libs\set > > m3-libs\slisp > > m3-libs\sortedtableextras > > m3-libs\table-list > > m3-libs\tempfiles > > m3-libs\tcl > > m3-comm\tcp > > m3-sys\cm3ide > > m3-comm\udp > > m3-libs\libsio > > m3-libs\libbuf > > m3-libs\debug > > m3-libs\listfuncs > > m3-libs\embutils > > m3-libs\m3tk-misc > > m3-www\http > > m3-libs\binIO > > m3-libs\commandrw > > m3-comm\tapi > > m3-comm\serial > > m3-tools\m3tk > > m3-tools\mtex > > m3-tools\m3totex > > m3-tools\m3tohtml > > m3-tools\m3scan > > m3-tools\m3markup > > m3-tools\m3browser > > m3-tools\cmpdir > > m3-tools\cmpfp > > m3-tools\dirfp > > m3-tools\uniq > > m3-comm\netobj > > m3-comm\netobjd > > m3-comm\stubgen > > m3-comm\events > > m3-comm\rdwr > > m3-comm\sharedobj > > m3-comm\sharedobjgen > > m3-db\odbc > > m3-db\postgres95 > > m3-db\db > > m3-db\smalldb > > m3-db\stablegen > > m3-db\stable > > m3-ui\X11R4 > > m3-ui\ui > > m3-ui\PEX > > m3-ui\vbtkit > > m3-ui\cmvbt > > m3-ui\jvideo > > m3-ui\videovbt > > m3-www\web > > m3-www\proxy > > m3-ui\formsvbtpixmaps > > m3-ui\formsvbt > > m3-ui\formsview > > m3-ui\formsedit > > m3-ui\codeview > > m3-tools\cvsup\suplib > > m3-tools\cvsup\client > > m3-tools\cvsup\server > > m3-tools\cvsup\cvpasswd > > m3-ui\mg > > m3-ui\mgkit > > m3-ui\opengl > > m3-ui\anim3D > > m3-ui\zeus > > m3-ui\m3zume > > m3-obliq\synloc > > m3-obliq\synex > > m3-obliq\metasyn > > m3-obliq\obliqrt > > m3-obliq\obliqparse > > m3-obliq\obliqprint > > m3-obliq\obliq > > m3-obliq\obliqlibemb > > m3-obliq\obliqlibm3 > > m3-obliq\obliqlibui > > m3-obliq\obliqlibanim > > m3-obliq\obliqsrvstd > > m3-obliq\obliqsrvui > > m3-obliq\obliqbinmin > > m3-obliq\obliqbinstd > > m3-obliq\obliqbinui > > m3-obliq\obliqbinanim > > m3-obliq\obliqlib3D > > m3-obliq\visualobliq > > m3-obliq\vocgi > > m3-obliq\voquery > > m3-obliq\vorun > > m3-ui\webvbt > > m3-tools\recordheap > > m3-tools\rehearsecode > > m3-tools\replayheap > > m3-tools\showheap > > m3-tools\shownew > > m3-tools\showthread > > m3-ui\juno-2\juno-app\pkl-fonts > > m3-ui\juno-2\juno-machine > > m3-ui\juno-2\juno-compiler > > m3-ui\juno-2\juno-app > > m3-demo\cube > > m3-demo\calculator > > m3-demo\fisheye > > m3-demo\mentor > > caltech-parser\cit_common > > caltech-parser\m3tmplhack > > caltech-parser\cit_util > > caltech-parser\term > > m3-libs\deepcopy > > caltech-parser\paneman > > caltech-parser\paneman\kemacs > > caltech-parser\drawcontext > > caltech-parser\drawcontext\dcpane > > caltech-parser\drawcontext\kgv > > caltech-parser\hack > > caltech-parser\m3browserhack > > caltech-parser\parserlib\ktoklib > > caltech-parser\parserlib\klexlib > > caltech-parser\parserlib\kyacclib > > caltech-parser\parserlib\ktok > > caltech-parser\parserlib\klex > > caltech-parser\parserlib\kyacc > > caltech-parser\parserlib\kext > > caltech-parser\parserlib\parserlib > > caltech-parser\parserlib\parserlib\test > > m3-tools\pp > > m3-tools\kate > > m3-libs\sgml > > m3-www\deckscape > > m3-www\webscape > > m3-www\webcat > > m3-ui\bicycle > > m3-games\badbricks > > m3-games\columns > > m3-games\fours > > m3-games\maze > > m3-games\solitaire > > m3-games\tetris > > ---END-of-List--- > > > > > > > > > > > > > > > > Here are the errors and warnings I am seeing currently > in building all the packages listed above: > > > > > > > > --- processing package "m3-sys\m3cc" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > _m3000.sh:cd . && CFLAGS="-g -O2" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MA > > KEINFO=: ../gcc/configure -srcdir=../gcc > -disable-bootstrap -disable-intl -di > > sable-libgomp -disable-libmudflap -disable-libssp > -disable-nls -enable-languages > > =m3cg -enable-targets=all -disable-dependency-tracking > -disable-fixincludes -dis > > able-libgcc -disable-decimal-float > -disable-fixed-point | tee -a C:/cm3/Sandbox > > /cm3/m3-sys/m3cc/src/../NT386/_m3.log > > 'chmod' is not recognized as an internal or external > command, > > operable program or batch file. > > 'sh' is not recognized as an internal or external > command, > > operable program or batch file. > > "C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile", line > 385: quake runtime error: > > exit 1: sh -ec ./_m3000.sh > > --procedure-- -line- -file--- > > exec -- > > m3cc_Run 385 > C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > > include_dir 514 > C:\cm3\Sandbox\cm3\m3-sys\m3cc\src\m3makefile > > 4 C:\cm3\Sandbox\cm3\m3-sys\m3cc\NT386\m3make.args > > Fatal Error: package build failed > > > > > > > > > > --- processing package "m3-libs\libm3" --- > > --- building in NT386 --- > > "..\src\pickle\ver2\ConvertPacking.m3", line 170: > warning: not used (CheckInt32) > > 1 warning encountered > > > > > > > > > > --- processing package "m3-sys\cm3" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > missing CM3_VERSION_NUMBER will read version file > > missing CM3_VERSION_TEXT will read version file > > missing CM3_LAST_CHANGED will read version file > > > > > > > > > > --- processing package "m3-sys\m3gdb" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-sys\mklib" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling Main.m3 > > "..\src\Main.m3", line 28: warning: unrecognized > pragma (ignored) (UNALIGNED) > > 1 warning encountered > > > > > > > > > > --- processing package "m3-db\postgres95" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-ui\X11R4" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-ui\PEX" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-tools\cvsup\suplib" --- > > --- processing package "m3-tools\cvsup\client" --- > > --- processing package "m3-tools\cvsup\server" --- > > --- processing package "m3-tools\cvsup\cvpasswd" --- > > nothing attempts to build for these packages > > > > > > > > > > --- processing package "m3-ui\anim3D" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling Win_OpenGL_Base.m3 > > "..\src\win-opengl\Win_OpenGL_Base.m3", line 217: > warning: exception is never raised: GraphicsBase.Failure > > "..\src\win-opengl\Win_OpenGL_Base.m3", line 2156: > warning: potentially unhandled exception: > GraphicsBase.Failure > > 2 warnings encountered > > > > > > > > > > --- processing package "m3-obliq\obliqrt" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling ObValueCB.i3 > > "..\NT386\ObValueCB.i3", line 9: warning: not used > (ObValueRep) > > 1 warning encountered > > new source -> compiling ObValueCBProxy.i3 > > "..\NT386\ObValueCBProxy.i3", line 9: warning: not > used (ObValueRep) > > 1 warning encountered > > new source -> compiling ObValueSO.m3 > > "..\NT386\ObValueSO.m3", line 12: warning: not used > (AtomList) > > 1 warning encountered > > new exporters -> recompiling ObValueCBProxy.i3 > > "..\NT386\ObValueCBProxy.i3", line 9: warning: not > used (ObValueRep) > > 1 warning encountered > > > > > > > > > > --- processing package "caltech-parser\cit_common" > --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > unsupported m3_option value: "-X2 at -pg@" > > unsupported m3_option value: "-g" > > > > > > > > > > --- processing package "m3-libs\deepcopy" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling DeepCopy.m3 > > "..\src\DeepCopy.m3", line 56: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > > "..\src\DeepCopy.m3", line 61: warning: potentially > unhandled exception: > > "..\src\DeepCopy.m3", line 97: warning: exception is > never raised: > > 3 warnings encountered > > > > > > > > > > --- processing package > "caltech-parser\parserlib\klexlib" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RegExpTok.m3 > > "..\NT386\RegExpTok.m3", line 41: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > > 1 warning encountered > > > > > > > > > > --- processing package > "caltech-parser\parserlib\parserlib\test" --- > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok > ..\src\Calc.t -o CalcTok.i3 > > The system cannot find the path specified. > > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: > quake runtime error: exit 1: > C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok > ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > > exec -- > > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > > include_dir 4 > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > > 4 > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > > > > > > > > > --- processing package "m3-tools\pp" --- > > nothing attempts to build for this package > > > > > > > > > > --- processing package "m3-tools\kate" --- > > --- building in NT386 --- > > KDESHARE not found; please define it! > > > > > > > > > > Regards, > > > > Randy Coleburn > > > > ------------------------------ > > Message: 4 > Date: Wed, 29 Jul 2009 20:34:25 +0200 > From: Olaf Wagner > Subject: [M3devel] m3cc build broken > To: m3devel at elegosoft.com > Message-ID: <20090729203425.wq5rkzvdc8gc8o88 at mail.elegosoft.com> > Content-Type: text/plain; charset=ISO-8859-15; > DelSp="Yes"; > ??? format="flowed" > > It looks as if the m3cc builds have broken after the last > commit to the release branch: > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > error: > ignoring ../src/m3overrides > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", > line 292: quake runtime error: undefined variable:? > build_dir > > --procedure--? -line-? -file--- > m3cc_Run? ? ? ? ? > 292??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > include_dir? ? > ???485??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > ? ? ? ? ? ? ? ? > ? ???4??? > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > Fatal Error: package build failed > > What's going on there? Why is build_dir suddenly > undefined? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 5 > Date: Wed, 29 Jul 2009 19:12:54 +0000 > From: Jay K > Subject: Re: [M3devel] m3cc build broken > To: Olaf , > m3devel > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > sorry, fixed now, agreed it is odd, I don't understand, > undid my simple seeming change > > - Jay > > > ---------------------------------------- > > Date: Wed, 29 Jul 2009 20:34:25 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3cc build broken > > > > It looks as if the m3cc builds have broken after the > last > > commit to the release branch: > > > > http://hudson.modula3.com:8080/job/cm3-m3cc-AMD64_LINUX/9/ > > http://hudson.modula3.com:8080/job/cm3-m3cc-FreeBSD4/11/ > > > > error: > > ignoring ../src/m3overrides > > > > > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", > line 292: quake runtime error: undefined variable: > > build_dir > > > > --procedure-- -line- -file--- > > m3cc_Run 292 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > > include_dir 485 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile > > 4 > > > /usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args > > > > Fatal Error: package build failed > > > > What's going on there? Why is build_dir suddenly > undefined? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner > | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > Message: 6 > Date: Wed, 29 Jul 2009 21:23:39 +0200 > From: Olaf Wagner > Subject: Re: [M3devel] m3cc build broken > To: Jay K > Cc: m3devel > Message-ID: <20090729212339.q3a9jlwty8oc0ksk at mail.elegosoft.com> > Content-Type: text/plain;??? > charset=UTF-8;??? > DelSp="Yes";??? format="flowed" > > Quoting Jay K : > > > sorry, fixed now, agreed it is odd, I don't > understand, undid my??? > > simple seeming change > > Never mind. The make-dist.sh script seems to be broken, > too. > Have a look at the end of? > http://hudson.modula3.com:8080/job/cm3-lastok-build-AMD64_LINUX/111/console. > > I guess I'll postpone package build again... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > ? ? ? ? ? ? ? ? > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96? mobile: +49 177 2345 > 869? fax: +49 30 23 45 86 95 > ? ? http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > ------------------------------ > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > End of M3devel Digest, Vol 33, Issue 113 > **************************************** > From rcoleburn at scires.com Thu Jul 30 18:57:38 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 12:57:38 -0400 Subject: [M3devel] cl on windows In-Reply-To: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> Message-ID: <4A719845.1E75.00D7.1@scires.com> Olaf: I don't think you want to be doing this with cygwin. That would mean you are executing in a cygwin environment, not a true Windows-only environment. For the Visual Studio command line to work, you have to run the script that sets up the environment variables. From the Windows Start menu, there should be a menu tree labeled "Visual C++ 9.0 Express Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". Choosing this item from the menu will bring up a command prompt with the environment set up properly. Alternately, you can run the following command from an existing command prompt window: "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat x86" Note that the above command line assumes you have installed Visual C++ 2008 Express Edition. The paths may be different for different versions of the software. Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or cm3SetupCmdEnv.CMD), they do this all for you. Regards, Randy Coleburn >>> Olaf Wagner 7/30/2009 12:30 PM >>> kind of consistent user interface: elego at wagner ~/work/cm3 $ type cl cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) elego at wagner ~/work/cm3 $ cl elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -version elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl -help elego at wagner ~/work/cm3 $ echo $? 53 elego at wagner ~/work/cm3 $ cl /help elego at wagner ~/work/cm3 $ echo $? 53 Can it do something else? Visual Studio Setup completely broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 30 19:23:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 19:23:56 +0200 Subject: [M3devel] cl on windows In-Reply-To: <4A719845.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Thanks for the answer, Randy. I had just remembered that I needed to set a number of variables. Attached is the shell script I came up with. Compilation works now without a problem. I get as far as linking: new source -> compiling WinUserC.c -> archiving m3core.lib link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 9 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** This seems to be a problem in the cm3 configuration files, right? More evidence: elego at wagner ~/work/cm3 $ (cd m3-libs/m3core; cm3 -commands -build -keep) --- building in NT386 --- cd NT386 ignoring ..\src\m3overrides rm .M3SHIP rm .M3OVERRIDES inhale m3core.m3x -> archiving m3core.lib rm m3core.lib rm m3core.lib rm m3core.lib.sa rm m3core.dll rm m3core.def rm m3core.lst rm m3core.dll.manifest rm m3core.pdb rm _m3responsefile0.txt rm _m3responsefile1.txt rm m3core.ilk rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk mklib @_m3responsefile0.txt 2>&1 > m3core.lst rm m3core.lib rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk link @_m3responsefile1.txt 2>&1 > m3core.lst link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 6 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. cd .. elego at wagner ~/work/cm3 $ cat m3-libs/m3core/NT386/_m3responsefile1.txt -nodefaultlib -debug -incremental:no -opt:ref -delayload:wsock32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll delayimp.lib -def:m3core.def -dll -out:m3core.dll -noentry hand.obj dtoa.obj libgcc.obj RTHooks.io RTHooks.mo [...lots of objects removed...] kernel32.lib msvcrt.lib Olaf PS: I don't think that just returning 53 is the correct way to remind users that some environment settings are missing though :-) Quoting Randy Coleburn : > Olaf: > > I don't think you want to be doing this with cygwin. That would mean > you are executing in a cygwin environment, not a true Windows-only > environment. > > For the Visual Studio command line to work, you have to run the script > that sets up the environment variables. From the Windows Start menu, > there should be a menu tree labeled "Visual C++ 9.0 Express > Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". > Choosing this item from the menu will bring up a command prompt with the > environment set up properly. > > Alternately, you can run the following command from an existing command > prompt window: "C:\Program Files\Microsoft Visual Studio > 9.0\VC\vcvarsall.bat x86" > > Note that the above command line assumes you have installed Visual C++ > 2008 Express Edition. The paths may be different for different versions > of the software. > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or > cm3SetupCmdEnv.CMD), they do this all for you. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 19:27:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 19:27:08 +0200 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <20090730192708.n77rrx3ta80ws88w@mail.elegosoft.com> Quoting Olaf Wagner : > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up with. Just in case somebody actually misses the promised attachment... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- # source me PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/BIN" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools" PATH="$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5" PATH="$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/VCPackages" PATH="$PATH:/cygdrive/c/Program Files//Microsoft SDKs/Windows/v6.0A/bin" PATH="$PATH:/cygdrive/c/WINDOWS/system32" PATH="$PATH:/cygdrive/c/WINDOWS" PATH="$PATH:/cygdrive/c/WINDOWS/System32/Wbem" PATH="$PATH:/cygdrive/c/Program Files/Microsoft SQL Server/90/Tools/binn/" PATH="$PATH:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin" PATH="$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/V/cygdrive/c/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools" INCLUDE='c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE' LIB='c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\lib;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB' LIBPATH='c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB' VCINSTALLDIR='c:\Program Files\Microsoft Visual Studio 9.0\VC' VSINSTALLDIR='c:\Program Files\Microsoft Visual Studio 9.0' DevEnvDir='c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE' Framework35Version='v3.5' FrameworkDir='c:\WINDOWS\Microsoft.NET\Framework' FrameworkVersion='v2.0.50727' export INCLUDE LIB LIBPATH VCINSTALLDIR VSINSTALLDIR DevEnvDir Framework35Version FrameworkDir FrameworkVersion From rcoleburn at scires.com Thu Jul 30 19:53:23 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 13:53:23 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> Message-ID: <4A71A555.1E75.00D7.1@scires.com> Jay: Your message was truncated, and provided much more info than I think I'm asking about. I simply need to know what packages have to be built, and in what order, to produce the minimal binary distribution for a given platform. In my case right now, platform is Windows XP or Vista. I had assumed, perhaps incorrectly, that "min" defines that set. But, I'm not sure. In particular, it looked like "front" might be building parts of the compiler that are needed. Or am I all wrong here, and rebuilding the compiler (i.e., using an old compiler to build a new version of itself) is a different process from building the minimal binary distribution? I also provided in my email a listing of all the group tags and the packages in each group for everyone's reference. (Sort of a sanity check on the correctness of PkgInfo.txt.) So, let me ask a concrete yes/no question, if one wanted to perform a complete cm3 installation on Windows, is the 13-step procedure outlined below correct? If not, please advise on changes needed. 1. Install Visual C++ 2008 Express Edition. 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. 8. mkdir "C:\cm3\bin\config" if it is missing 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". I know you've probably got scripts for all of this, but somewhere we need to document exactly what is required. Scripts are an expression of the requirements and they may contain bugs, so knowing what is supposed to happen, versus reading a script, is important. Regards, Randy >>> Jay K 7/29/2009 8:35 PM >>> I'm only going to answer partially for now.. > Are these really all that is needed > to build the "minimal" binary distribution? It depends on what you mean. The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows). That's it. You don't need any packages at all. You don't need m3core/libm3. I setup tinderbox a few times recently. In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far). What that lets you do is build the whole system, from the bottom of the dependency tree and on up. HISTORICALLY there have been some wrinkles here. And it made pretty good sense, I guess, to draw another line. Whether or not that will happen again, unclear. The specific wrinkles were: - Old compiler could not compile a new libm3, if new targets had been added That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler - Old compiler cannot compile m3core or libm3 that uses LONGINT. Now, I have a suspicion that these issues are not extremely rare but just somewhat rare. All compilation systems written in themselves have a circularity. The compiler depends on the compiler. Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make. Let's imagine, crazy, that all the identifiers were changed to lowercase. If "just" change the compiler, well then, you can't build the compiler. You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form. I feel like I might be missing something though. In any case..what are the scenarios? - People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith. Give these people "std" or a bunch of binary packages. These people, in the extreme impatience form, would not even like Olaf's workspace packages. - People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3. Today you give these people cm3, cm3cg, and config files. But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does. The difference in DEC SRC is that quake was written in C, so the division was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose). - Various (infinite) in between situations such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jul 30 21:35:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 19:35:13 +0000 Subject: [M3devel] cl on windows In-Reply-To: <4A719845.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: Cygwin is fine. Really. You can mix them. The problem is that both cl.exe and mspdb90.dll need to be in path, and VC link.exe needs to be ahead of Cygwin link.exe, or delete Cygwin link.exe. C:\Users\jay>which cl /cygdrive/c/msdev/90/VC/BIN/cl C:\Users\jay>which gcc /usr/bin/gcc C:\Users\jay>which cvs /usr/bin/cvs C:\Users\jay>gcc -v ... gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) C:\Users\jay>cvs Usage: cvs [cvs-options] command [command-options-and-arguments] ... C:\Users\jay>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] C:\Users\jay>which mspdb80.dll /cygdrive/c/msdev/90/Common7/IDE/mspdb80.dll C:\Users\jay>which link /cygdrive/c/msdev/90/VC/BIN/link - Jay ________________________________ > Date: Thu, 30 Jul 2009 12:57:38 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cl on windows > > > > > > > > Olaf: > > > > I don't think you want to be doing this with cygwin. That would mean you are executing in a cygwin environment, not a true Windows-only environment. > > > > For the Visual Studio command line to work, you have to run the script that sets up the environment variables. From the Windows Start menu, there should be a menu tree labeled "Visual C++ 9.0 Express Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". Choosing this item from the menu will bring up a command prompt with the environment set up properly. > > > > Alternately, you can run the following command from an existing command prompt window: "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat x86" > > > > Note that the above command line assumes you have installed Visual C++ 2008 Express Edition. The paths may be different for different versions of the software. > > > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or cm3SetupCmdEnv.CMD), they do this all for you. > > > > Regards, > > Randy Coleburn > >>>> Olaf Wagner 7/30/2009 12:30 PM>>> > kind of consistent user interface: > > elego at wagner ~/work/cm3 > $ type cl > cl is hashed (/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl) > > elego at wagner ~/work/cm3 > $ cl > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl -version > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl -help > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > elego at wagner ~/work/cm3 > $ cl /help > > elego at wagner ~/work/cm3 > $ echo $? > 53 > > Can it do something else? > Visual Studio Setup completely broken? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 30 21:48:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 19:48:38 +0000 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. Cygwin's link.exe is a synonym for ln.exe. > Attached is the shell script I came up with. Here are my mine for many environments. Of particular interest are: env\cm3\cm3.cygwin.bat env\cm3\cm3.vc90.bat env\test.bat used to work but I've deleted some of the toolsets You can see a lot of it works via composition. cm3.vc90.bat uses env\ms\vc90.bat - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 19:23:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cl on windows > > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up with. > > Compilation works now without a problem. I get as far as linking: > > new source -> compiling WinUserC.c > -> archiving m3core.lib > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 9 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > This seems to be a problem in the cm3 configuration files, right? > > More evidence: > > elego at wagner ~/work/cm3 > $ (cd m3-libs/m3core; cm3 -commands -build -keep) > --- building in NT386 --- > > cd NT386 > ignoring ..\src\m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale m3core.m3x > > -> archiving m3core.lib > rm m3core.lib > rm m3core.lib > rm m3core.lib.sa > rm m3core.dll > rm m3core.def > rm m3core.lst > rm m3core.dll.manifest > rm m3core.pdb > rm _m3responsefile0.txt > rm _m3responsefile1.txt > rm m3core.ilk > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > mklib @_m3responsefile0.txt 2>&1> m3core.lst > rm m3core.lib > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > link @_m3responsefile1.txt 2>&1> m3core.lst > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 6 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > cd .. > > elego at wagner ~/work/cm3 > $ cat m3-libs/m3core/NT386/_m3responsefile1.txt > -nodefaultlib > -debug > -incremental:no > -opt:ref > -delayload:wsock32.dll > -delayload:advapi32.dll > -delayload:gdi32.dll > -delayload:netapi32.dll > -delayload:user32.dll > -delayload:comctl32.dll > delayimp.lib > -def:m3core.def > -dll > -out:m3core.dll > -noentry > hand.obj > dtoa.obj > libgcc.obj > RTHooks.io > RTHooks.mo > [...lots of objects removed...] > kernel32.lib > msvcrt.lib > > > Olaf > > PS: I don't think that just returning 53 is the correct way to remind > users that some environment settings are missing though :-) > > Quoting Randy Coleburn : > >> Olaf: >> >> I don't think you want to be doing this with cygwin. That would mean >> you are executing in a cygwin environment, not a true Windows-only >> environment. >> >> For the Visual Studio command line to work, you have to run the script >> that sets up the environment variables. From the Windows Start menu, >> there should be a menu tree labeled "Visual C++ 9.0 Express >> Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". >> Choosing this item from the menu will bring up a command prompt with the >> environment set up properly. >> >> Alternately, you can run the following command from an existing command >> prompt window: "C:\Program Files\Microsoft Visual Studio >> 9.0\VC\vcvarsall.bat x86" >> >> Note that the above command line assumes you have installed Visual C++ >> 2008 Express Edition. The paths may be different for different versions >> of the software. >> >> Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or >> cm3SetupCmdEnv.CMD), they do this all for you. >> >> Regards, >> Randy Coleburn > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- A non-text attachment was scrubbed... Name: env.zip Type: application/x-zip-compressed Size: 63495 bytes Desc: not available URL: From jay.krell at cornell.edu Thu Jul 30 22:11:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 20:11:41 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A71A555.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> Message-ID: Randy, the short answer is: Find a goal state in a graph, which you haven't clearly done, walk that graph from the bottom up, and if there are circularities (there are, you need to have cm3 first, before you can build cm3), you need to download prebuilt files from somewhere (cm3 and mklib). Everything else is filling in the details of the goal state, discovering the circularities, and that we have the graph recorded in a redundant fashion in pkginfo.txt. The real data is the m3makefiles. longer answer: Randy, what is a "minimal" distribution? You have't defined the goal. What is "build"? You haven't defined the goal. I could just say: "Whatever you need, to build it, just download it from here." I'll define it as some arbitrary very minimal compiler and runtime set, specifically m3core and libm3. But you can have working Modula-3 programs certainly without libm3. And some Modula-3 programs will have a GUI so will want more libraries. What is "minimal"? And depending on future changes, the steps might change. Or maybe just pkginfo.txt will change. If there is no documentation and there is code, the code is the documentation. A lot of the code is declarative -- you look at the import statements in m3makefile. For given package foo, say "cm3", you walk the list of imports transitively. I'm not sure cm3 actually uses libm3 for example, and maybe it won't in the future. This is a very real point. pkginfo.txt duplicates dependency information by nature of being "in the correct order", but that information is already contained in the m3makefiles. Your questions have made me realize the redundancy we have and that we should fix it. Or, really, older cm3 did not use sysutils, but now it does. Things change. And you haven't really defined the goal. Instead of "walk pkginfo.txt in order", it should be "pick a package you want, say cm3, and build its dependency tree from the bottom up, using the m3makefiles to discover that tree, plus the PKGS file to locate packages". I'm going to make up a goal that might resemble yours and correct your instructions. > 1. Install Visual C++ 2008 Express Edition. ok. Though you don't need all of it by far. You don't need the entire IDE. > > 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. No. You don't need all of it. You only need two files -- cm3.exe and mklib.exe. Other platforms need cm3cg and don't need mklib. Except you never really need cm3cg, it falls out of the instructions -- cm3 can build it. It depends on how much you want to build vs. download. And optionally the config files. You can get them from either the source tree or download them. See, two legitimate places for things -- download from one place or another. > > > 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. No. You don't need all of it. You need, roughly, only m3-libs\m3core, m3-libs\libm3, m3-libs\sysutils, some of m3-sys. m3-sys/m3cc is needed for most platforms, but not the gcc-apple directory, that's only for iphone. > > 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" Not needed. > > 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" Not needed. > > 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. Many ways to do that. > > > 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. Multiple ways to do this but ok. > > > 8. mkdir "C:\cm3\bin\config" if it is missing ok. You can just mkdir unconditionally. > > > 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" You don't need all of it, but ok, that is what I do. > > > 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: > > INSTALL_ROOT = path() & "/.." > > include(path() & "/config/" & HOST) ok > > > 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) No. Well, it depends on the goal. Really. You already have a cm3. "min" gives you m3core and libm3. Combine that with the cm3 you already have and great, you have a slightly larger more useful set of libraries. > > > 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. NOt really. The repitition isn't doing what you say. Look at the group called "front". Which isn't completely accurate since it includes m3cc. Perhaps there should be a group compiler. But really, again, this is cm3 plus its transitive dependencies. I think maybe we need to partly ditch "groups". In paritcular, "groups" should contain useful end results and not their dependencies. m3middle doesn't belong in any group, it is just implied by cm3. Seriously. But the scripts don't currently read m3makefiles. Redoing things in cm3 would be better? > > > 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". Ok. Sort of. > > I know you've probably got scripts for all of this Yep. > Scripts are an expression of the requirements Sometimes it is the other way around. - Jay From wagner at elegosoft.com Thu Jul 30 22:16:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:16:42 +0200 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <442486.20009.qm@web56806.mail.re3.yahoo.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> Message-ID: <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Olaf, > > www.eiserloh.org is my personal machine, on which I do most of my > personal stuff. I have been putting things on its web > server so other people can get to those public items I > have made. > > I will probably have to get an account on birch or something. > > Speaking of debian packages, I am building a virtual machine > for ARM_LINUX using qemu. Currently installing Debian Lenny > in it. Inside which I will build set of CM3 debian packages > for ARM. > > Following that: PPC_LINUX. > > Now if I could only get my "nslu2" up and running again. :-) Everyone known on the m3 mailing lists will easily get an ssh login to birch without problems by just sending a public ssh key to our administrators. You can use that account to commit to the M3 repository, to test and compile on birch (as long as you don't bring the machine down) and to generally look around (M3 web server, tinderbox, Hudson). We can create a staging area for new designs on the web server, too. I can also create logins on the new Hudson server for all those who are interested. Access is simply password restricted there and not really secure though. All that should be described in our web pages, too, but it's probably buried and well hidden :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 22:19:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:19:19 +0200 Subject: [M3devel] cl on windows In-Reply-To: References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> Message-ID: <20090730221919.j5ufrc8qroc4swog@mail.elegosoft.com> Quoting Jay K : > > Cygwin is fine. Really. You can mix them. > The problem is that both cl.exe and mspdb90.dll need to be in path, > and VC link.exe needs to be ahead of Cygwin link.exe, or delete > Cygwin link.exe. Oh my, stupid me! Wrong link command... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Jul 30 22:30:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Jul 2009 22:30:37 +0200 Subject: [M3devel] cl on windows In-Reply-To: References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> Quoting Jay K : > Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. > Cygwin's link.exe is a synonym for ln.exe. One step further thanks to your hint. Now dynamic linking fails: Creating library sysutils.lib and object sysutils.exp LINK : fatal error LNK1101: incorrect MSPDB80.DLL version; recheck installation of this product As I haven't installed anything on this VM and only have ssh access, I've got no idea what/how to check. It's just a copy of a standard VM installation we have as far as I know. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 30 22:44:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Jul 2009 20:44:08 +0000 Subject: [M3devel] cl on windows In-Reply-To: <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <20090730223037.fi0s4phwhs4gc8o0@mail.elegosoft.com> Message-ID: Hm. Backup. I'm not sure what's going on so I'll be more conservative. Did you install Visual C++ or copy it around? Did you set %PATH% or run the start menu shortcut that Randy suggested? Try installing rather than copying. Try the start menu shortcut, then set PATH=%PATH%;c:\cygwin\bin (or PATH=C:\cygwin\bin;%PATH% if you delete the Cygwin link.exe) Kill any mspdbsrv.exe process. Not repeatedly, but once. Did you start with my VC80 cm3 or my VC90 cm3? - Jay ---------------------------------------- > Date: Thu, 30 Jul 2009 22:30:37 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; khaeusler at elegosoft.com > Subject: Re: [M3devel] cl on windows > > Quoting Jay K : > >> Either delete Cygwin's link.exe or make sure VC's is earlier in %PATH%. >> Cygwin's link.exe is a synonym for ln.exe. > > One step further thanks to your hint. Now dynamic linking fails: > > Creating library sysutils.lib and object sysutils.exp > LINK : fatal error LNK1101: incorrect MSPDB80.DLL version; recheck > installation of this product > > As I haven't installed anything on this VM and only have ssh access, > I've got no idea what/how to check. It's just a copy of a standard > VM installation we have as far as I know. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From dragisha at m3w.org Fri Jul 31 00:20:39 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 00:20:39 +0200 Subject: [M3devel] M3Config In-Reply-To: References: Message-ID: <1248992439.2801.9.camel@faramir.m3w.org> I have code reading data structure information from .M3WEB files.... And that code used M3Config for obvious things... Now when you killed it, how I am supposed (in portable way) to find these files? :) TIA, dd On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > So..I was wondering..what were the original authors thinking? > > And there was that comment about the file containing the data upon > install. > Which seemed wrong to me. > > They were probably thinking of the way 3.6 was packaged and > distributed -- everyone built the system from source, upon building > m3build/m3ship from C and m3 from assembly. > > That isn't a bad model, but we probably want both. > > There are at least three times the paths can be computed/recorded: > 1) when you build libm3 > 2) when you install libm3 > #1 and #2 may or may not be close in time and have the same result. > 3) by parsing cm3.cfg as needed > > #2 is more efficient than #3 and matches the old code, but #3 is how I > left it, probably ok. > > - Jay > -- Dragi?a Duri? From dragisha at m3w.org Fri Jul 31 00:17:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 00:17:47 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <645960.77867.qm@web56801.mail.re3.yahoo.com> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> Message-ID: <1248992267.2801.7.camel@faramir.m3w.org> cm3 -? ... > CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, > "make DESTDIR=" behaviour for cm3 > This is one patch I've introduced earlier and it's excellent conduit for RPM packaging scripts I develop. I am using it like this: > export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT > > ./scripts/do-pkg.sh realclean m3core libm3 > > ./scripts/do-pkg.sh buildship m3core libm3 > Please let me know if your script fails on you mentioning mkdir failure. I have workaround for it (as Jay did not accept my report as a bug). I'll put my RPM script in repository RSN. dd On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: > Hi Jay, > > Do you know of any way to tell the build system that the > final installation directory is located in one place, but > that the software is to actually be shipped (temporarily) > to a staging directory. > > Specifically, libm3/src/config contains a m3makefile that > derives the M3Config interface, containing a number of > paths to the installation root directory. > > This is the normal situation for most people, but I am > installing to a temporary directory, for packaging purposes. > The packaging software later installs the package into > the correct location. > > Whenever I build the system, M3Config always contains > the paths to my staging area. > > I would like some way of specifying to the build system > that the final (or real) installation root is one thing, > but "ship" would actually install into a different one. > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 03:27:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 01:27:23 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1248992267.2801.7.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: > I have workaround for it (as Jay did not accept my report as a bug). I believe I fixed it. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Fri, 31 Jul 2009 00:17:47 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > cm3 -? > ... >> CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, >> "make DESTDIR=" behaviour for cm3 >> > > This is one patch I've introduced earlier and it's excellent conduit for > RPM packaging scripts I develop. I am using it like this: > > >> export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT >> >> ./scripts/do-pkg.sh realclean m3core libm3 >> >> ./scripts/do-pkg.sh buildship m3core libm3 >> > > Please let me know if your script fails on you mentioning mkdir failure. > I have workaround for it (as Jay did not accept my report as a bug). > > > I'll put my RPM script in repository RSN. > > dd > > On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: >> Hi Jay, >> >> Do you know of any way to tell the build system that the >> final installation directory is located in one place, but >> that the software is to actually be shipped (temporarily) >> to a staging directory. >> >> Specifically, libm3/src/config contains a m3makefile that >> derives the M3Config interface, containing a number of >> paths to the installation root directory. >> >> This is the normal situation for most people, but I am >> installing to a temporary directory, for packaging purposes. >> The packaging software later installs the package into >> the correct location. >> >> Whenever I build the system, M3Config always contains >> the paths to my staging area. >> >> I would like some way of specifying to the build system >> that the final (or real) installation root is one thing, >> but "ship" would actually install into a different one. >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 03:30:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 01:30:04 +0000 Subject: [M3devel] M3Config In-Reply-To: <1248992439.2801.9.camel@faramir.m3w.org> References: <1248992439.2801.9.camel@faramir.m3w.org> Message-ID: It was partly unsupportable and you can trivially replace it with MxConfig. Please try that -- MxConfig. MxConfig.Get() I recall. We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 00:20:39 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config > > I have code reading data structure information from .M3WEB files.... And > that code used M3Config for obvious things... Now when you killed it, > how I am supposed (in portable way) to find these files? :) > > TIA, > dd > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: >> So..I was wondering..what were the original authors thinking? >> >> And there was that comment about the file containing the data upon >> install. >> Which seemed wrong to me. >> >> They were probably thinking of the way 3.6 was packaged and >> distributed -- everyone built the system from source, upon building >> m3build/m3ship from C and m3 from assembly. >> >> That isn't a bad model, but we probably want both. >> >> There are at least three times the paths can be computed/recorded: >> 1) when you build libm3 >> 2) when you install libm3 >> #1 and #2 may or may not be close in time and have the same result. >> 3) by parsing cm3.cfg as needed >> >> #2 is more efficient than #3 and matches the old code, but #3 is how I >> left it, probably ok. >> >> - Jay >> > -- > Dragi?a Duri? > From rcoleburn at scires.com Fri Jul 31 03:54:08 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 30 Jul 2009 21:54:08 -0400 Subject: [M3devel] cl on windows In-Reply-To: <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> Message-ID: <4A721600.1E75.00D7.1@scires.com> Olaf: Using the "do-cm3.cmd" script that I checked in, I am currently able to compile and link on both Windows XP and Vista all packages listed in PkgInfo.txt , except for the packages that have been disabled via the m3makefile for NT386. Again, I suspect your problem may be in using cygwin. I infer that you are using cygwin based on the path name below "C:\cygwin\usr\local...". Again, this is further evidence why there needs to be a distinction between a CM3 installation for Windows and one for cygwin running on Windows; and why the supporting scripts may need to be different. Of course, if Jay succeeds in getting the python scripts to be truly "portable" between the various platforms, it may cut down on the maintenance, since we won't need a different script for every platform. For now, I'm holding fast to Windows CMD because I can make it work and I don't have to install anything else to get it to work. Regards, Randy >>> Olaf Wagner 7/30/2009 1:23 PM >>> Thanks for the answer, Randy. I had just remembered that I needed to set a number of variables. Attached is the shell script I came up with. Compilation works now without a problem. I get as far as linking: new source -> compiling WinUserC.c -> archiving m3core.lib link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 9 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. *** execution of cm3 -build -override $RARGS -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** This seems to be a problem in the cm3 configuration files, right? More evidence: elego at wagner ~/work/cm3 $ (cd m3-libs/m3core; cm3 -commands -build -keep) --- building in NT386 --- cd NT386 ignoring ..\src\m3overrides rm .M3SHIP rm .M3OVERRIDES inhale m3core.m3x -> archiving m3core.lib rm m3core.lib rm m3core.lib rm m3core.lib.sa rm m3core.dll rm m3core.def rm m3core.lst rm m3core.dll.manifest rm m3core.pdb rm _m3responsefile0.txt rm _m3responsefile1.txt rm m3core.ilk rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk mklib @_m3responsefile0.txt 2>&1 > m3core.lst rm m3core.lib rm c:\WINDOWS\TEMP\qk rm c:\WINDOWS\TEMP\qk link @_m3responsefile1.txt 2>&1 > m3core.lst link: invalid option -- n Try `link --help' for more information. "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake runtime error: dynamic link library creation failed, see C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more information --procedure-- -line- -file--- error -- make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common Library -- include_dir 48 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile 6 C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args Fatal Error: procedure "make_lib" defined in "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. cd .. elego at wagner ~/work/cm3 $ cat m3-libs/m3core/NT386/_m3responsefile1.txt -nodefaultlib -debug -incremental:no -opt:ref -delayload:wsock32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll delayimp.lib -def:m3core.def -dll -out:m3core.dll -noentry hand.obj dtoa.obj libgcc.obj RTHooks.io RTHooks.mo [...lots of objects removed...] kernel32.lib msvcrt.lib Olaf PS: I don't think that just returning 53 is the correct way to remind users that some environment settings are missing though :-) Quoting Randy Coleburn : > Olaf: > > I don't think you want to be doing this with cygwin. That would mean > you are executing in a cygwin environment, not a true Windows-only > environment. > > For the Visual Studio command line to work, you have to run the script > that sets up the environment variables. From the Windows Start menu, > there should be a menu tree labeled "Visual C++ 9.0 Express > Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". > Choosing this item from the menu will bring up a command prompt with the > environment set up properly. > > Alternately, you can run the following command from an existing command > prompt window: "C:\Program Files\Microsoft Visual Studio > 9.0\VC\vcvarsall.bat x86" > > Note that the above command line assumes you have installed Visual C++ > 2008 Express Edition. The paths may be different for different versions > of the software. > > Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or > cm3SetupCmdEnv.CMD), they do this all for you. > > Regards, > Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 06:14:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 00:14:54 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> Message-ID: <4A7236FD.1E75.00D7.1@scires.com> Jay: Thanks for your reply. I really appreciate your patience in dealing with all my questions, especially during this busy time preparing for the release. In response, I offer the following and also ask a few more questions: My use of the term "minimal" is consistent with what has been documented in the working release documentation. Namely, that "min" is the smallest distribution we plan to make available, versus "std" that contains a "standard" distribution, versus "all" that contains everything. Now as to the exact composition of "min" and "std" that is part of my question. I assumed someone (you, Olaf, Tony, ?) has defined what these mean. Further, if you look at PkgInfo.txt, it appears that these definitions are recorded there, but again back to my question as to whether these definitions are accurate, complete, what the "cm3 community" wants/expects, and whether my understanding of how they are used in the context of cm3 is indeed correct. I am well-versed in compilers and operating systems principles and design, so I don't need a lecture on these fundamentals. My line of questioning is concrete with respect to the impending cm3 release. My use of the term "build" is in the context of "cm3 -build", and to be useful, subsequently "cm3 -ship". As a software/systems engineer, I understand what you mean when you say that the code is the documentation when there is no external documentation. However, I would hope you agree that no external documentation is generally a bad thing. Hence my questions. I'm not a python code writer yet, though I'm confident I could be, given some time to learn. Thus, I can't presently rely on reading a python script as documentation. I am confident that if you, Olaf, Tony, or someone can confirm or correct my understanding of what I've posed as the way to install the "min" distribution on Windows and "build" the rest, that I can and will be able to document this process externally for others to review. We can then check scripts to see if they deviate from the documentation and make changes (to either scripts or documentation) as needed to reflect reality. You state that I have not defined the "goal." Let me attempt to make this obvious. I'm not trying to upset the apple cart here or change the way you work to achieve progress/success. My goal simply is to "understand" wrt the impending release so I can document, and so I can "do the right thing" to make this work correctly on my system. We can discuss in the future how things should change for the next release. Thanks for help with my 13-steps. I have some comments and a few more questions below. WRT #1, Yes, I know I may not need all of Visual Studio, but most users will just choose the typical installation. If we have specific minimums that need to be present, we should identify (document) those for users who choose to customize their installation. WRT #2, you have to start somewhere. If we have both "min" and "std" distributions, one can choose which to start with, but your discussion of which parts to trim out of "min" should not be left to the end user. The release team needs to establish what constitutes "min". My "opinion" is that "min" should contain only what is necessary for a working cm3 compiler, given the dependency on the platform-specific linker. Using "min" one should be able to build (cm3 -build -ship) all other packages. Anything added to "min" that isn't necessary to accomplish building the remaining packages would be considered superfluous, in my opinion. Some amount of superfluous on a given platform may be tolerable in order to reach consistency among all supported platforms regarding the composition of "min". Thus, if cm3cg is needed for "min" on some platforms, but not all, it is tolerable (IMO) to make it a standard component of "min" on all platforms. WRT #3, point taken. However, unless we have an easy way to specify and checkout only those parts of the tree relevant to a particular platform, checking out everything ensures you haven't missed something that is going to cause problems later. WRT#4, although doc may not be needed to run cm3, it is needed for folks to reference and understand cm3. This is a long-standing gripe of mine that we don't make the installation of doc part of the typical installation. The naive user new to cm3 normally expects to get some documentation. If the default is no documentation, how does the poor sap know how to get the documentation and install it? Also, cm3ide, does have links to the doc folder. If you click on these links and they are broken, the average user is going to rate cm3 as a poor product and move on to something else. Why create a problem for the new user? Give him the documentation he needs by default and let the expert user remove it if it is unwanted. I know that Critical Mass's 4.1 installation put the doc folder there. When did someone decide it wasn't appropriate for the default installation? WRT#5, examples is needed for cm3ide. Right now, my bet is that most everyone in the cm3 community doesn't know they should copy the examples folder to the root of their cm3 installation. That's because Reactor wasn't open-sourced until recently as cm3ide. Right now the only documentation about this is a README file buried in the repository and even that wouldn't be there if I hadn't put it there. Again, don't create a problem for the new user. The "typical" installation choice should install it by default. Let the expert user choose to remove it as part of a custom install if it is not wanted. WRT#6, agree. That's why I wasn't specific on how to do it, but for the newbie, it would probably be best to list at least one way. WRT#7, agree. I was just stating my interpretation of what you had communicated to me earlier about setting up config properly. WRT#8, ok, but you do get an error message if the folder exists already. WRT#9, ditto #7 WRT#11, now we are finally getting to the meat of my questions. So, if I understand you correctly, you are saying that building the "min" group of packages does not recreate for me exactly what is being published as the "min" distribution. In my view, we have a conflict of terminology here that needs to be cleaned up. So what exactly is "min" as defined in PkgInfo.txt if it doesn't represent the minimal binary install? Furthermore, if I want to use cm3 to build the sources for the compiler itself, it would seem from your comments that "min" won't do it. Which packages need to built, and in what order, to recreate cm3.exe ? Again you ask about the goal here, so let me be more explicit. Given that cm3 continues to evolve and that minimal distributions are created at unpredictable intervals, if one wants to ensure the cm3 compiler is up-to-date with the latest sources, one would want to start with some existing cm3 installation and build and ship the compiler's source package(s) along with any other packages where a dependency exists. In these instructions, I started with obtaining the latest "min" distribution, then grabbed the current source tree, so I want to proceed from this point to build a current cm3 compiler and any other requisite components to again create a "minimal" installation on my platform. From there, one can build some/all of the remaining packages. WRT#12, the repeat is due to my prior understanding. Perhaps this is incorrect, or perhaps the recent changes have made this unnecessary. But, it seems my understanding of how to rebuild cm3.exe is flawed given your response to #11. Are you saying I should use "front" to build cm3.exe? Am I the only one to whom all this is unclear? Again, we need to document for understanding. WRT#13, not sure what you mean by "sort of". What are the caveats? Regarding your comment at the end about scripts, I will respectfully choose to disagree with you and hope that we work together to improve documentation. After all, if we all get run over by a truck, what we know in our brains isn't available to others unless we've documented it somewhere. Thanks for your patience in putting up with all my questions! Thanks also for all you are doing for cm3! Regards, Randy Coleburn >>> Jay K 7/30/2009 4:11 PM >>> Randy, the short answer is: Find a goal state in a graph, which you haven't clearly done, walk that graph from the bottom up, and if there are circularities (there are, you need to have cm3 first, before you can build cm3), you need to download prebuilt files from somewhere (cm3 and mklib). Everything else is filling in the details of the goal state, discovering the circularities, and that we have the graph recorded in a redundant fashion in pkginfo.txt. The real data is the m3makefiles. longer answer: Randy, what is a "minimal" distribution? You have't defined the goal. What is "build"? You haven't defined the goal. I could just say: "Whatever you need, to build it, just download it from here." I'll define it as some arbitrary very minimal compiler and runtime set, specifically m3core and libm3. But you can have working Modula-3 programs certainly without libm3. And some Modula-3 programs will have a GUI so will want more libraries. What is "minimal"? And depending on future changes, the steps might change. Or maybe just pkginfo.txt will change. If there is no documentation and there is code, the code is the documentation. A lot of the code is declarative -- you look at the import statements in m3makefile. For given package foo, say "cm3", you walk the list of imports transitively. I'm not sure cm3 actually uses libm3 for example, and maybe it won't in the future. This is a very real point. pkginfo.txt duplicates dependency information by nature of being "in the correct order", but that information is already contained in the m3makefiles. Your questions have made me realize the redundancy we have and that we should fix it. Or, really, older cm3 did not use sysutils, but now it does. Things change. And you haven't really defined the goal. Instead of "walk pkginfo.txt in order", it should be "pick a package you want, say cm3, and build its dependency tree from the bottom up, using the m3makefiles to discover that tree, plus the PKGS file to locate packages". I'm going to make up a goal that might resemble yours and correct your instructions. > 1. Install Visual C++ 2008 Express Edition. ok. Though you don't need all of it by far. You don't need the entire IDE. > > 2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc.. No. You don't need all of it. You only need two files -- cm3.exe and mklib.exe. Other platforms need cm3cg and don't need mklib. Except you never really need cm3cg, it falls out of the instructions -- cm3 can build it. It depends on how much you want to build vs. download. And optionally the config files. You can get them from either the source tree or download them. See, two legitimate places for things -- download from one place or another. > > > 3. Checkout complete CVS CM3 tree and place in say "C:\cm3\Sandbox", so now Sandbox has m3-sys, m3-libs, scripts, etc. No. You don't need all of it. You need, roughly, only m3-libs\m3core, m3-libs\libm3, m3-libs\sysutils, some of m3-sys. m3-sys/m3cc is needed for most platforms, but not the gcc-apple directory, that's only for iphone. > > 4. Copy "C:\cm3\Sandbox\doc" folder to "C:\cm3\doc" Not needed. > > 5. Copy "C:\cm3\Sandbox\examples" folder to "C:\cm3\examples" Not needed. > > 6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path. Many ways to do that. > > > 7. For each file in "Sandbox\m3-sys\cm3install\src\config-no-install" and "Sandbox\m3-sys\cm3install\src\config" delete the corresponding file in "C:\cm3\bin" if it exists. Multiple ways to do this but ok. > > > 8. mkdir "C:\cm3\bin\config" if it is missing ok. You can just mkdir unconditionally. > > > 9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\config-no-install" to "C:\cm3\bin\config" You don't need all of it, but ok, that is what I do. > > > 10. (Re)create "C:\cm3\cm3.cfg" to contain the following 2 lines only: > > INSTALL_ROOT = path() & "/.." > > include(path() & "/config/" & HOST) ok > > > 11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\PkgInfo.txt". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?) No. Well, it depends on the goal. Really. You already have a cm3. "min" gives you m3core and libm3. Combine that with the cm3 you already have and great, you have a slightly larger more useful set of libraries. > > > 12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff. NOt really. The repitition isn't doing what you say. Look at the group called "front". Which isn't completely accurate since it includes m3cc. Perhaps there should be a group compiler. But really, again, this is cm3 plus its transitive dependencies. I think maybe we need to partly ditch "groups". In paritcular, "groups" should contain useful end results and not their dependencies. m3middle doesn't belong in any group, it is just implied by cm3. Seriously. But the scripts don't currently read m3makefiles. Redoing things in cm3 would be better? > > > 13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std". Ok. Sort of. > > I know you've probably got scripts for all of this Yep. > Scripts are an expression of the requirements Sometimes it is the other way around. - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 31 06:28:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 00:28:55 -0400 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: Randy, I think this is a very useful exposition of the requirements for release distributions. I trust that your concerns can be addressed by Jay and Olaf. I must admit that, at this point, I have lost track of where things stand in the release installation process and hope soon to bring myself up to date. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 31 Jul 2009, at 00:14, Randy Coleburn wrote: > Jay: > > Thanks for your reply. I really appreciate your patience in dealing > with all my questions, especially during this busy time preparing > for the release. > > In response, I offer the following and also ask a few more questions: > > My use of the term "minimal" is consistent with what has been > documented in the working release documentation. Namely, that "min" > is the smallest distribution we plan to make available, versus "std" > that contains a "standard" distribution, versus "all" that contains > everything. > > Now as to the exact composition of "min" and "std" that is part of > my question. I assumed someone (you, Olaf, Tony, ?) has defined > what these mean. Further, if you look at PkgInfo.txt, it appears > that these definitions are recorded there, but again back to my > question as to whether these definitions are accurate, complete, > what the "cm3 community" wants/expects, and whether my understanding > of how they are used in the context of cm3 is indeed correct. > > I am well-versed in compilers and operating systems principles and > design, so I don't need a lecture on these fundamentals. My line of > questioning is concrete with respect to the impending cm3 release. > > My use of the term "build" is in the context of "cm3 -build", and to > be useful, subsequently "cm3 -ship". > > As a software/systems engineer, I understand what you mean when you > say that the code is the documentation when there is no external > documentation. However, I would hope you agree that no external > documentation is generally a bad thing. Hence my questions. I'm > not a python code writer yet, though I'm confident I could be, given > some time to learn. Thus, I can't presently rely on reading a > python script as documentation. I am confident that if you, Olaf, > Tony, or someone can confirm or correct my understanding of what > I've posed as the way to install the "min" distribution on Windows > and "build" the rest, that I can and will be able to document this > process externally for others to review. We can then check scripts > to see if they deviate from the documentation and make changes (to > either scripts or documentation) as needed to reflect reality. > > You state that I have not defined the "goal." Let me attempt to > make this obvious. I'm not trying to upset the apple cart here or > change the way you work to achieve progress/success. My goal simply > is to "understand" wrt the impending release so I can document, and > so I can "do the right thing" to make this work correctly on my > system. We can discuss in the future how things should change for > the next release. > > Thanks for help with my 13-steps. I have some comments and a few > more questions below. > > WRT #1, Yes, I know I may not need all of Visual Studio, but most > users will just choose the typical installation. If we have > specific minimums that need to be present, we should identify > (document) those for users who choose to customize their installation. > > WRT #2, you have to start somewhere. If we have both "min" and > "std" distributions, one can choose which to start with, but your > discussion of which parts to trim out of "min" should not be left to > the end user. The release team needs to establish what constitutes > "min". My "opinion" is that "min" should contain only what is > necessary for a working cm3 compiler, given the dependency on the > platform-specific linker. Using "min" one should be able to build > (cm3 -build -ship) all other packages. Anything added to "min" that > isn't necessary to accomplish building the remaining packages would > be considered superfluous, in my opinion. Some amount of > superfluous on a given platform may be tolerable in order to reach > consistency among all supported platforms regarding the composition > of "min". Thus, if cm3cg is needed for "min" on some platforms, but > not all, it is tolerable (IMO) to make it a standard component of > "min" on all platforms. > > WRT #3, point taken. However, unless we have an easy way to specify > and checkout only those parts of the tree relevant to a particular > platform, checking out everything ensures you haven't missed > something that is going to cause problems later. > > WRT#4, although doc may not be needed to run cm3, it is needed for > folks to reference and understand cm3. This is a long-standing > gripe of mine that we don't make the installation of doc part of the > typical installation. The naive user new to cm3 normally expects to > get some documentation. If the default is no documentation, how > does the poor sap know how to get the documentation and install it? > Also, cm3ide, does have links to the doc folder. If you click on > these links and they are broken, the average user is going to rate > cm3 as a poor product and move on to something else. Why create a > problem for the new user? Give him the documentation he needs by > default and let the expert user remove it if it is unwanted. I know > that Critical Mass's 4.1 installation put the doc folder there. > When did someone decide it wasn't appropriate for the default > installation? > > WRT#5, examples is needed for cm3ide. Right now, my bet is that > most everyone in the cm3 community doesn't know they should copy the > examples folder to the root of their cm3 installation. That's > because Reactor wasn't open-sourced until recently as cm3ide. Right > now the only documentation about this is a README file buried in the > repository and even that wouldn't be there if I hadn't put it > there. Again, don't create a problem for the new user. The > "typical" installation choice should install it by default. Let the > expert user choose to remove it as part of a custom install if it is > not wanted. > > WRT#6, agree. That's why I wasn't specific on how to do it, but for > the newbie, it would probably be best to list at least one way. > > WRT#7, agree. I was just stating my interpretation of what you had > communicated to me earlier about setting up config properly. > > WRT#8, ok, but you do get an error message if the folder exists > already. > > WRT#9, ditto #7 > > WRT#11, now we are finally getting to the meat of my questions. So, > if I understand you correctly, you are saying that building the > "min" group of packages does not recreate for me exactly what is > being published as the "min" distribution. In my view, we have a > conflict of terminology here that needs to be cleaned up. So what > exactly is "min" as defined in PkgInfo.txt if it doesn't represent > the minimal binary install? Furthermore, if I want to use cm3 to > build the sources for the compiler itself, it would seem from your > comments that "min" won't do it. Which packages need to built, and > in what order, to recreate cm3.exe ? > > Again you ask about the goal here, so let me be more explicit. > Given that cm3 continues to evolve and that minimal distributions > are created at unpredictable intervals, if one wants to ensure the > cm3 compiler is up-to-date with the latest sources, one would want > to start with some existing cm3 installation and build and ship the > compiler's source package(s) along with any other packages where a > dependency exists. In these instructions, I started with obtaining > the latest "min" distribution, then grabbed the current source tree, > so I want to proceed from this point to build a current cm3 compiler > and any other requisite components to again create a "minimal" > installation on my platform. From there, one can build some/all of > the remaining packages. > > WRT#12, the repeat is due to my prior understanding. Perhaps this > is incorrect, or perhaps the recent changes have made this > unnecessary. But, it seems my understanding of how to rebuild > cm3.exe is flawed given your response to #11. Are you saying I > should use "front" to build cm3.exe? Am I the only one to whom all > this is unclear? Again, we need to document for understanding. > > WRT#13, not sure what you mean by "sort of". What are the caveats? > > Regarding your comment at the end about scripts, I will respectfully > choose to disagree with you and hope that we work together to > improve documentation. After all, if we all get run over by a > truck, what we know in our brains isn't available to others unless > we've documented it somewhere. > > Thanks for your patience in putting up with all my questions! > Thanks also for all you are doing for cm3! > > Regards, > Randy Coleburn > >>>> Jay K 7/30/2009 4:11 PM >>> > > > Randy, the short answer is: > > Find a goal state in a graph, which you haven't clearly done, walk > that graph from the bottom up, and if there are circularities (there > are, you need to have cm3 first, before you can build cm3), you need > to download prebuilt files from somewhere (cm3 and mklib). > > > Everything else is filling in the details of the goal state, > discovering the circularities, and that we have the graph recorded > in a redundant fashion in pkginfo.txt. The real data is the > m3makefiles. > > > longer answer: > > > > Randy, what is a "minimal" distribution? You have't defined the goal. > What is "build"? You haven't defined the goal. > I could just say: "Whatever you need, to build it, just download it > from here." > > > I'll define it as some arbitrary very minimal compiler and runtime > set, specifically m3core and libm3. > But you can have working Modula-3 programs certainly without libm3. > And some Modula-3 programs will have a GUI so will want more > libraries. > What is "minimal"? > And depending on future changes, the steps might change. > Or maybe just pkginfo.txt will change. > If there is no documentation and there is code, the code is the > documentation. > > > A lot of the code is declarative -- you look at the import > statements in m3makefile. > For given package foo, say "cm3", you walk the list of imports > transitively -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 07:05:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 01:05:45 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content Message-ID: <4A7242E8.1E75.00D7.1@scires.com> Jay et al: On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. In particular, these are: BUILD_DIR PKG_USE DOC_INSTALL INSTALL_ROOT INITIAL_CM3_IDE_BROWSER INITIAL_CM3_IDE_EDITOR If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jul 31 08:10:35 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 08:10:35 +0200 Subject: [M3devel] M3Config In-Reply-To: References: <1248992439.2801.9.camel@faramir.m3w.org> Message-ID: <1249020635.2801.476.camel@faramir.m3w.org> Of course I do not insist. I need function, form is what someone with wider insight can decide much better. It's a bit... unusual... to depend on m3quake, but then... it's probably very unusual to read .M3WEB's too. I'll try it, thanks. dd On Fri, 2009-07-31 at 01:30 +0000, Jay K wrote: > It was partly unsupportable and you can trivially replace it with MxConfig. > Please try that -- MxConfig. MxConfig.Get() I recall. > > > We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). > > > - Jay > > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 31 Jul 2009 00:20:39 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] M3Config > > > > I have code reading data structure information from .M3WEB files.... And > > that code used M3Config for obvious things... Now when you killed it, > > how I am supposed (in portable way) to find these files? :) > > > > TIA, > > dd > > > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > >> So..I was wondering..what were the original authors thinking? > >> > >> And there was that comment about the file containing the data upon > >> install. > >> Which seemed wrong to me. > >> > >> They were probably thinking of the way 3.6 was packaged and > >> distributed -- everyone built the system from source, upon building > >> m3build/m3ship from C and m3 from assembly. > >> > >> That isn't a bad model, but we probably want both. > >> > >> There are at least three times the paths can be computed/recorded: > >> 1) when you build libm3 > >> 2) when you install libm3 > >> #1 and #2 may or may not be close in time and have the same result. > >> 3) by parsing cm3.cfg as needed > >> > >> #2 is more efficient than #3 and matches the old code, but #3 is how I > >> left it, probably ok. > >> > >> - Jay > >> > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 08:45:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 06:45:51 +0000 Subject: [M3devel] cl on windows In-Reply-To: <4A721600.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <4A721600.1E75.00D7.1@scires.com> Message-ID: > Again, I suspect your problem may be in using cygwin. I infer that you are using cygwin based on the path name below "C:\cygwin\usr\local...". Again, really, no. All both Cygwin and the vcvars32.bat are adding elements to %PATH%, and %LIB%, and %INCLUDE%, and adding files within the directories within %PATH%. The only way in which they collide is when they have file names in common, such as link.exe, or, indeed, python.exe. (or multiple copies of cygwin1.dll, because it uses a shared section, which is a security bug, which they seem to ignore that and just claim that Windows is insecure so they have no problem making things worse...multiple users who don't trust themselves have read/write access to some of each other's memory in this setup..) > if Jay succeeds in getting the python scripts to be truly "portable" > between the various platforms Again, I already have. I wrote them on a Mac to start, and since them have run on then OpenBSD, NetBSD, FreeBSD, Linux (Gentoo, Debian, maybe Red Hat), Solaris, NT, HP-UX, Cygwin, Interix, Darwin (not the full Mac OSX, which is where they ran first), and maybe more that is all I can remember. What are the errors you get? I have asked a few times. - Jay From jay.krell at cornell.edu Fri Jul 31 08:48:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 06:48:59 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content In-Reply-To: <4A7242E8.1E75.00D7.1@scires.com> References: <4A7242E8.1E75.00D7.1@scires.com> Message-ID: BUILD_DIR is defined. cm3 requires it too. It just isn't necessarily defined in the toplevel file, but in a file that gets included. > PKG_USE I believe that is also defined but I'll check. > DOC_INSTALL I doubt that is defined because I never saw it used. I can add it back. > INSTALL_ROOT That is certainly defined, and very important. > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR These are probably also not defined because I never saw them used. I can add them back..but they are actually very user specific. I can add defaults like: BROWSER=iexplore.exe EDITOR=notepad.exe BROWSER=firefox-bin EDITOR=/usr/bin/vi I'll do a little reserach and try to find defaults that work. - Jay ________________________________ > Date: Fri, 31 Jul 2009 01:05:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content > > > > > > > > Jay et al: > > > > On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. > > > > cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". > > > > I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. > > > > At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. > > > > In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. > > > > In particular, these are: > > BUILD_DIR > > PKG_USE > > DOC_INSTALL > > INSTALL_ROOT > > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR > > > > If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. > > > > I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. > > > > It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. > > > > Regards, > > Randy Coleburn From jay.krell at cornell.edu Fri Jul 31 09:06:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:06:15 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1248992267.2801.7.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: Please consider that you don't really need this CM3_INSTALL_PREFIX feature. I understand what it does. And the implementation is pretty small and ok. I don't mind leaving it in. And I think I fixed the problem with it. I hope it is clear that it isn't really needed. I will explain why. It isn't needed because the default ship location is adequate. The default ship location is the location of cm3, or one level up from there, or uh, whatever the config file says, but that is what it usually is. Now, granted, the location of cm3 "right now" might not be what you want. However, copying cm3 to where you want shipping to go is cheap, if in fact you are after building the whole system. If you are after just building a few packages, then, indeed, what I am saying makes less/no sense. gcc for example, is a bit heavyweight to copy around. It is many files. However cm3 is very small. If you want to ship somewhere else, you can do this: mkdir -p /tmp/foo/bin/config cd /tmp/foo/bin cp /usr/local/bin/cm3 . cp /usr/local/bin/cm3.cfg . cp /usr/local/bin/config/* config export PATH=/tmp/foo/bin:$PATH That's it. Then go about building the distribution, I'm not sure of the order here, but I'm sick of arguing about scripts and package groups and pkginfo.txt, the whole lot is unnecessary. cd $CVSROOT/m3-sys/m3cc cm3 -build cm3 -ship cd $CVSROOT/m3-libs/m3core cm3 -build cm3 -ship cd $CVSROOT/m3-libs/libm3 cm3 -build cm3 -ship cd $CVSROOT/m3-libs/sysutils cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3quake cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3middle cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3front cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3linker cm3 -build cm3 -ship cd $CVSROOT/m3-sys/m3back cm3 -build cm3 -ship cd $CVSROOT/m3-sys/cm3 cm3 -build cm3 -ship oops this line doesn't do anything useful # rem next line makes up for previous line not "working" cp build_dir/cm3 /tmp/foo/bin and continue on your way building/shipping whatever Again, if you just want to package up some gui apps for example, not the whole system from scratch, then CM3_INSTALL_PREFIX becomes more useful. I do wonder if the usage should have been cm3 -ship DESTDIR=/tmp/foo to follow widespread existing practice, but ok either way. Apple also uses a different name like DSTROOT for their linker/assembler and such. This technique is how I build distributions and I believe how Olaf does too, since I based my code on his. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Fri, 31 Jul 2009 00:17:47 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > cm3 -? > ... >> CM3_INSTALL_PREFIX path prefix to prepend to filenames being installed, >> "make DESTDIR=" behaviour for cm3 >> > > This is one patch I've introduced earlier and it's excellent conduit for > RPM packaging scripts I develop. I am using it like this: > > >> export CM3_INSTALL_PREFIX=$RPM_BUILD_ROOT >> >> ./scripts/do-pkg.sh realclean m3core libm3 >> >> ./scripts/do-pkg.sh buildship m3core libm3 >> > > Please let me know if your script fails on you mentioning mkdir failure. > I have workaround for it (as Jay did not accept my report as a bug). > > > I'll put my RPM script in repository RSN. > > dd > > On Wed, 2009-07-15 at 18:19 -0700, Peter Eiserloh wrote: >> Hi Jay, >> >> Do you know of any way to tell the build system that the >> final installation directory is located in one place, but >> that the software is to actually be shipped (temporarily) >> to a staging directory. >> >> Specifically, libm3/src/config contains a m3makefile that >> derives the M3Config interface, containing a number of >> paths to the installation root directory. >> >> This is the normal situation for most people, but I am >> installing to a temporary directory, for packaging purposes. >> The packaging software later installs the package into >> the correct location. >> >> Whenever I build the system, M3Config always contains >> the paths to my staging area. >> >> I would like some way of specifying to the build system >> that the final (or real) installation root is one thing, >> but "ship" would actually install into a different one. >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 09:39:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:39:01 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: I'm sorry but I'm feeling very impatient... > Namely, that "min" is the smallest distribution we plan to make available Ok, that is clearer. That is not scientific but a matter of a decision. We could decide that min==std, not a bad decision really, since it gives users fewer confusing choices, and provides one package per platform, with no overlap. On the downside, it isn't small and some people might say we look fat. > My "opinion" is that "min" should contain only what is > necessary for a working cm3 compiler Now you have made a policy decision. An acceptable one. But not necessarily how it should and not necessarily consistent with some other things. > Anything added to "min" that isn't necessary to accomplish > building the remaining packages would be considered superfluous, > in my opinion. > Some amount of superfluous on a given platform may be > tolerable in order to reach consistency among all supported > platforms regarding the composition of "min". Thus, > if cm3cg is needed for "min" on some platforms, but not all, > it is tolerable (IMO) to make it a standard component of "min" > on all platforms. cm3cg doesn't really make sense on NT386 though. I've probably thrown it in somewhat by accident. If it is there, it'll depend on Cygwin, and NT386 will just ignore it completely, except for wasted diskspace, network traffic. > WRT#4, although doc may not be needed to run cm3, it is needed > for folks to reference and understand cm3. Now you are expanding the definition. The documentation is all online too. I'm certainly fine with including the documentation. Just be clear that "min"'s definition is expanding. (I'm fine with not distributing min at all, as I said, min==std?) > The naive user new to cm3 normally expects to get some documentation. I don't expect naive users to build cm3 themselves. This is in fact a reason not to provide min at all, but std. That way, the naive person who thinks he is expert won't make a mistake. Really. On the other hand, there are the masochists among us who use the Debian "netinst" and chose no additional packages during setup. :) If one has the time/patience, it can also be educational to create arbitrary difficult situations and work your way out of them. Really. (Why does anyone use Linux after all?) > If the default is no documentation, how does the poor sap know > how to get the documentation and install it? Poor saps should use "std", not "min". Right? What is "min"? The "minimum" distribution that is useful for "everyone" or the minimal distribution to build cm3? I should correct myself by the way. cm3cg is not needed in "min". It is "easily" just not quickly built from just cm3 and the m3-sys/m3cc part of the tree, and really cm3 is hardly needed for that (but cm3 is definitely needed for building everything else, so needed overall). > [Jay] docs/examples I think it was > The "typical" installation choice should install it by default. "typical" or "min"? > WRT#11, now we are finally getting to the meat of my questions. So, > if I understand you correctly, you are saying that building the "min" > group of packages does not recreate for me exactly what You must start with a prebuilt compiler (cm3). Whether you rebuild the compiler or not is somewhat a matter of taste. Indeed it is more tasteful to build it. In which case indeed, you need to build "front", but "front" need not be in the distribution. "front" is in fact basically just cm3, and I think cm3cg. Again again again, the "package groups" are just a redundant encoding of the dependency tree that is encoded in the m3makefiles. We could the entire scripts directory and pretty much everything would work about the same. It would just be a little tedious. More and more I think we should actually delete a lot of this. We should keep the PKGS file, or make cm3 able to figure it out, and the "scripts" should just accept an end goal -- "cm3", and it should read the m3makefiles and build the dependency graph from the buttom up to the goal. There could be special goal called "all", AND we could have the broken m3makefiles all filter themselves out. Perhaps a special group called "test", whose membership is implied by path? But now, you see, the more of these features I add, the more I'm back to reinventing these minor little scripts and package groups that we have. But do you see, that these aren't sort of all that significant? What you need to build is whatever m3makefiles lists in imports, and follow the transitive closure. And cm3cg is sort of different -- because it isn't a linked/library dependency, but rather because the config files tries to run a program (cm3cg) and that program needs to therefore exist somewhere. That is, the linked/library dependencies are encoded in a nice declarative way in the m3makefiles but the dependency on cm3cg is encoded in an imperative way. My interpretion of "min" has been roughly a minimal distribution that one can start with in order to build cm3, EVEN IF old cm3 cannot build m3core and libm3 from current source. The part I don't understand is that last point -- is it considered a recurring problem? Where is the line? What about sysutils? Is sysutils expected to be forever bound to be buildable by arbitrarily old compilers? Do we make a release shortly any such incompatibilities occur? Do we in fact not cater to such incompatibilities, and "min" therefore does NOT include m3core and libm3? Historically there was actually a more recurring problem here, around the list of targets. That is gone now. However there are still occasional problems like LONGINT. It seems to me this is somewhat of a problem of predicting the future, which is impossible. But also taking out very cheap insurance against the only fairly small number of bad futures. That is, throwing in m3core and libm3 is cheap, and it allows for future versions to not be compilable with old cm3, and that not being a big deal. This is all a bit gray and heuristic however. If today you start with a 5.4 or such cm3, indeed, you cannot build m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3. If you start with yesterday's cm3 however, you can build today's entire system, without also having yesterday's m3core/libm3 (nor cm3cg). See? It depends. And mitigating the worst case is perhaps worthwhile and cheap. And it depends because the system is necessarily circular. ("necessary" because the compiler is written in Modula-3) Breaking circular dependencies requires cheating. Changes in circular graphs can require cheating differently. If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay From dragisha at m3w.org Fri Jul 31 09:47:37 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 09:47:37 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> Message-ID: <1249026457.2801.578.camel@faramir.m3w.org> On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: > mkdir -p /tmp/foo/bin/config > cd /tmp/foo/bin > cp /usr/local/bin/cm3 . > cp /usr/local/bin/cm3.cfg . > cp /usr/local/bin/config/* config > export PATH=/tmp/foo/bin:$PATH Please tell me /usr/local/bin/config/* is mistake here... -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 09:54:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:54:19 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1249026457.2801.578.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> Message-ID: sorry /usr/local/cm3/bin -- or wherever cm3 is installed. I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. Just as /tmp/foo can be replaced by anything. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 09:47:37 +0200 > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: >> mkdir -p /tmp/foo/bin/config >> cd /tmp/foo/bin >> cp /usr/local/bin/cm3 . >> cp /usr/local/bin/cm3.cfg . >> cp /usr/local/bin/config/* config >> export PATH=/tmp/foo/bin:$PATH > > Please tell me /usr/local/bin/config/* is mistake here... > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jul 31 09:59:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 07:59:07 +0000 Subject: [M3devel] package groups question In-Reply-To: <4A7236FD.1E75.00D7.1@scires.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: [truncated right about here..] If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changes. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay From jay.krell at cornell.edu Fri Jul 31 10:02:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 08:02:33 +0000 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: [wow severely truncated that time...trying again] [truncated right about here..] If we do this, it is probably a good idea to also include sysutils in min. But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific. > > > WRT#13, not sure what you mean by "sort of". What are the caveats? I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all". Now, actually, we might be missing a few. "std" is more like everything we know to compile. For example m3-pkgtools is missing from "std". But if you get it to compile, we'll add it. I believe that is the intent. Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would. Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Fri, 31 Jul 2009 07:59:07 +0000 > Subject: Re: [M3devel] package groups question > > > [truncated right about here..] > > > If we do this, it is probably a good idea to also include sysutils in min From dragisha at m3w.org Fri Jul 31 10:00:11 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 10:00:11 +0200 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> Message-ID: <1249027211.2801.593.camel@faramir.m3w.org> My question was about location and names of secondary config files. Are these changed again? What would ne shipping procedure for compiler installation? Something new there? /cm3 is excellent idea, but on organized system (and if you package for general public) some standard location is preferred. I will change my locatio to /opt/cm3 now. dd On Fri, 2009-07-31 at 07:54 +0000, Jay K wrote: > sorry /usr/local/cm3/bin -- or wherever cm3 is installed. > I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. > > Just as /tmp/foo can be replaced by anything. > > - Jay > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 31 Jul 2009 09:47:37 +0200 > > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > > > On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: > >> mkdir -p /tmp/foo/bin/config > >> cd /tmp/foo/bin > >> cp /usr/local/bin/cm3 . > >> cp /usr/local/bin/cm3.cfg . > >> cp /usr/local/bin/config/* config > >> export PATH=/tmp/foo/bin:$PATH > > > > Please tell me /usr/local/bin/config/* is mistake here... > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jul 31 10:20:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 08:20:49 +0000 Subject: [M3devel] M3Config contains paths to installation directory. In-Reply-To: <1249027211.2801.593.camel@faramir.m3w.org> References: <645960.77867.qm@web56801.mail.re3.yahoo.com> <1248992267.2801.7.camel@faramir.m3w.org> <1249026457.2801.578.camel@faramir.m3w.org> <1249027211.2801.593.camel@faramir.m3w.org> Message-ID: The current layout is indeed: installroot/bin/cm3 installroot/bin/cm3.cfg installroot/bin/cm3cg installroot/bin/config/* There are imho too many files in config to put them in bin. cm3.cfg is just a two line stub: INSTALL_ROOT = path() & "/.." include(path() & "/config/" & HOST) If you really want the files in, e.g. installroot/etc.: INSTALL_ROOT = path() & "/.." include(path() & "/../etc/" & HOST) or another example you could use is: cd $CVSROOT/m3-sys/cminstall/src/config-no-install cp *.common installroot/cm3/bin cp target installroot/cm3/bin/cm3.cfg or what I use: cd $CVSROOT/m3-sys/cminstall/src/config-no-install cp cm3.cfg installroot/cm3/bin That cm3.cfg delegates out to CM3_ROOT/m3-sys/cminstall/src/config-no-install so that when I am editing in CM3_ROOT/m3-sys/cminstall/src/config-no-install, I don't have to keep copying the file around and never accidentally edit the copy and then wipe it out by recopying it. It is an excellent model imho, but also not for everyone (ie. if you don't have the CVS tree!). It also provides for changing the TARGET somewhat on the fly on "multiarch" systems like NT386+Cygwin, SOLsun + SOLgnu, but I'm no longer liking that model and have started having /cm3, /cm3.cygwin, /cm3.interix on such systems instead. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 10:00:11 +0200 > CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] M3Config contains paths to installation directory. > > My question was about location and names of secondary config files. Are > these changed again? What would ne shipping procedure for compiler > installation? Something new there? > > /cm3 is excellent idea, but on organized system (and if you package for > general public) some standard location is preferred. I will change my > locatio to /opt/cm3 now. > > dd > > On Fri, 2009-07-31 at 07:54 +0000, Jay K wrote: >> sorry /usr/local/cm3/bin -- or wherever cm3 is installed. >> I actually use just /cm3, but I often alter my examples to fit more common practise. Sometimes it helps confuse people less to use typical concrete paths instead of metata syntax. Esp. because puting less than and greater than around things causes hotmail to remove them, so lame, so tempting meta syntax doesn't work.. >> >> Just as /tmp/foo can be replaced by anything. >> >> - Jay >> >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> Date: Fri, 31 Jul 2009 09:47:37 +0200 >>> CC: m3devel at elegosoft.com; eiserlohpp at yahoo.com >>> Subject: Re: [M3devel] M3Config contains paths to installation directory. >>> >>> On Fri, 2009-07-31 at 07:06 +0000, Jay K wrote: >>>> mkdir -p /tmp/foo/bin/config >>>> cd /tmp/foo/bin >>>> cp /usr/local/bin/cm3 . >>>> cp /usr/local/bin/cm3.cfg . >>>> cp /usr/local/bin/config/* config >>>> export PATH=/tmp/foo/bin:$PATH >>> >>> Please tell me /usr/local/bin/config/* is mistake here... >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From wagner at elegosoft.com Fri Jul 31 12:10:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 12:10:14 +0200 Subject: [M3devel] cl on windows In-Reply-To: <4A721600.1E75.00D7.1@scires.com> References: <20090730183050.ut5udrs5wc8cgg8c@mail.elegosoft.com> <4A719845.1E75.00D7.1@scires.com> <20090730192356.h6z1d3yatcwwg0w0@mail.elegosoft.com> <4A721600.1E75.00D7.1@scires.com> Message-ID: <20090731121014.dhdyyt3af4s0gcoo@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > Using the "do-cm3.cmd" script that I checked in, I am currently able to > compile and link on both Windows XP and Vista all packages listed in > PkgInfo.txt , except for the packages that have been disabled via the > m3makefile for NT386. > > Again, I suspect your problem may be in using cygwin. I infer that you > are using cygwin based on the path name below "C:\cygwin\usr\local...". I don't think that the problems I encounter are related to cygwin. Think of it as just another shell to execute the production scripts. It's probably simply a broken Visual Studio installation. Tools like compiler and linker should work the same being called from bash or python or cmd.exe. > Again, this is further evidence why there needs to be a distinction > between a CM3 installation for Windows and one for cygwin running on > Windows; and why the supporting scripts may need to be different. Of > course, if Jay succeeds in getting the python scripts to be truly > "portable" between the various platforms, it may cut down on the > maintenance, since we won't need a different script for every platform. There should be a distinction concerning the target platforms (like NT386/NT386GNU as it used to be, but we'll rather use more adequate names). However, this is separate from the production and regression scripts we use. They may be written in shell or python or quake or whatever. I've always used the shell framework, so that's what I use to setup Hudson regression currently. > For now, I'm holding fast to Windows CMD because I can make it work and > I don't have to install anything else to get it to work. That's completely OK and a worthwhile task in itself. Unless you rewrite all the regression scripts in cmd, I cannot really use that though. Olaf > Regards, > Randy > >>>> Olaf Wagner 7/30/2009 1:23 PM >>> > Thanks for the answer, Randy. I had just remembered that I needed to > set a number of variables. Attached is the shell script I came up > with. > > Compilation works now without a problem. I get as far as linking: > > new source -> compiling WinUserC.c > -> archiving m3core.lib > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 9 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > *** execution of cm3 -build -override $RARGS > -DROOT='C:\\cygwin\\home\\elego\\work\\cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' failed *** > > This seems to be a problem in the cm3 configuration files, right? > > More evidence: > > elego at wagner ~/work/cm3 > $ (cd m3-libs/m3core; cm3 -commands -build -keep) > --- building in NT386 --- > > cd NT386 > ignoring ..\src\m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale m3core.m3x > > -> archiving m3core.lib > rm m3core.lib > rm m3core.lib > rm m3core.lib.sa > rm m3core.dll > rm m3core.def > rm m3core.lst > rm m3core.dll.manifest > rm m3core.pdb > rm _m3responsefile0.txt > rm _m3responsefile1.txt > rm m3core.ilk > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > mklib @_m3responsefile0.txt 2>&1 > m3core.lst > rm m3core.lib > rm c:\WINDOWS\TEMP\qk > rm c:\WINDOWS\TEMP\qk > link @_m3responsefile1.txt 2>&1 > m3core.lst > link: invalid option -- n > Try `link --help' for more information. > "C:\cygwin\usr\local\cm3\bin/config\NT386.common", line 725: quake > runtime error: dynamic link library creation failed, see > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3core.lst for more > > information > > > --procedure-- -line- -file--- > error -- > make_lib 725 C:\cygwin\usr\local\cm3\bin/config\NT386.common > Library -- > include_dir 48 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\src\m3makefile > 6 > C:\cygwin\home\elego\work\cm3\m3-libs\m3core\NT386\m3make.args > > > Fatal Error: procedure "make_lib" defined in > "C:\cygwin\usr\local\cm3\bin\cm3.cfg" failed. > > cd .. > > elego at wagner ~/work/cm3 > $ cat m3-libs/m3core/NT386/_m3responsefile1.txt > -nodefaultlib > -debug > -incremental:no > -opt:ref > -delayload:wsock32.dll > -delayload:advapi32.dll > -delayload:gdi32.dll > -delayload:netapi32.dll > -delayload:user32.dll > -delayload:comctl32.dll > delayimp.lib > -def:m3core.def > -dll > -out:m3core.dll > -noentry > hand.obj > dtoa.obj > libgcc.obj > RTHooks.io > RTHooks.mo > [...lots of objects removed...] > kernel32.lib > msvcrt.lib > > > Olaf > > PS: I don't think that just returning 53 is the correct way to remind > users that some environment settings are missing though :-) > > Quoting Randy Coleburn : > >> Olaf: >> >> I don't think you want to be doing this with cygwin. That would > mean >> you are executing in a cygwin environment, not a true Windows-only >> environment. >> >> For the Visual Studio command line to work, you have to run the > script >> that sets up the environment variables. From the Windows Start > menu, >> there should be a menu tree labeled "Visual C++ 9.0 Express >> Edition-->Visual Studio Tools-->Visual Studio 2008 Command Prompt". >> Choosing this item from the menu will bring up a command prompt with > the >> environment set up properly. >> >> Alternately, you can run the following command from an existing > command >> prompt window: "C:\Program Files\Microsoft Visual Studio >> 9.0\VC\vcvarsall.bat x86" >> >> Note that the above command line assumes you have installed Visual > C++ >> 2008 Express Edition. The paths may be different for different > versions >> of the software. >> >> Of course, if you use my CMD files (e.g., cm3PromptHere.CMD or >> cm3SetupCmdEnv.CMD), they do this all for you. >> >> Regards, >> Randy Coleburn > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Jul 31 14:31:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 08:31:15 -0400 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> Message-ID: <20090731123115.GA17620@topoi.pooq.com> On Thu, Jul 30, 2009 at 10:16:42PM +0200, Olaf Wagner wrote: > Quoting Peter Eiserloh : > > >Hi Olaf, > > > >www.eiserloh.org is my personal machine, on which I do most of my > >personal stuff. I have been putting things on its web > >server so other people can get to those public items I > >have made. > > > >I will probably have to get an account on birch or something. > > > >Speaking of debian packages, I am building a virtual machine > >for ARM_LINUX using qemu. Currently installing Debian Lenny > >in it. Inside which I will build set of CM3 debian packages > >for ARM. I wonder if that will make it easy to install CM3 programs on Nokia's internet tablets. -- hendrik From jay.krell at cornell.edu Fri Jul 31 14:36:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 12:36:26 +0000 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: <20090731123115.GA17620@topoi.pooq.com> References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> <20090731123115.GA17620@topoi.pooq.com> Message-ID: We should be a little careful with ARM_LINUX imho. And MIPS_LINUX. Those target name might be ok, and they'd refer to Linux 2.6+ with glibc. Many ARM and MIPS Linux systems aren't that. ARM has old ABI and new ABI, at the kernel level. It it also common to replace glibc with uclibc. I don't know if they are binary compatible or not. My Linux/arm machine/device is old ABI and uclibc. It seems that if you are building your own kernel, it is trivial to use old ABI. It isn't like it is incompatible with new hardware, I think. I think whoever put together the Western Digital MyBook World Edition just took the default. MIPS..well, I was surprised. I installed "Tomato" on my router. It is /very/ low end, but it does have a builtin SMB client, therefore it has infinite diskspace. It uses Linux 2.4, and I think/assume uclibc. MIPS also has big and little endian and I don't know if either is more common or if it is an even split. - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 08:31:15 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors > > On Thu, Jul 30, 2009 at 10:16:42PM +0200, Olaf Wagner wrote: >> Quoting Peter Eiserloh : >> >>>Hi Olaf, >>> >>>www.eiserloh.org is my personal machine, on which I do most of my >>>personal stuff. I have been putting things on its web >>>server so other people can get to those public items I >>>have made. >>> >>>I will probably have to get an account on birch or something. >>> >>>Speaking of debian packages, I am building a virtual machine >>>for ARM_LINUX using qemu. Currently installing Debian Lenny >>>in it. Inside which I will build set of CM3 debian packages >>>for ARM. > > I wonder if that will make it easy to install CM3 programs on Nokia's > internet tablets. > > -- hendrik From dragisha at m3w.org Fri Jul 31 14:43:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 31 Jul 2009 14:43:41 +0200 Subject: [M3devel] M3Config In-Reply-To: <1249020635.2801.476.camel@faramir.m3w.org> References: <1248992439.2801.9.camel@faramir.m3w.org> <1249020635.2801.476.camel@faramir.m3w.org> Message-ID: <1249044221.27649.235.camel@faramir.m3w.org> Uhoh. I would like to use MxConfig.Get(), ok. It is in m3quake. Depending on m3middle. Depending on sysutils. Looks a bit too heavy for simple "where is ...?" processing. Can this logic be moved so I don't have to dynamicaly link large chunk of compiler code in every program using this functionality? TIA, dd On Fri, 2009-07-31 at 08:10 +0200, Dragi?a Duri? wrote: > Of course I do not insist. I need function, form is what someone with > wider insight can decide much better. It's a bit... unusual... to depend > on m3quake, but then... it's probably very unusual to read .M3WEB's too. > I'll try it, thanks. > > dd > > On Fri, 2009-07-31 at 01:30 +0000, Jay K wrote: > > It was partly unsupportable and you can trivially replace it with MxConfig. > > Please try that -- MxConfig. MxConfig.Get() I recall. > > > > > > We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required). > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > From: dragisha at m3w.org > > > To: jay.krell at cornell.edu > > > Date: Fri, 31 Jul 2009 00:20:39 +0200 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] M3Config > > > > > > I have code reading data structure information from .M3WEB files.... And > > > that code used M3Config for obvious things... Now when you killed it, > > > how I am supposed (in portable way) to find these files? :) > > > > > > TIA, > > > dd > > > > > > On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote: > > >> So..I was wondering..what were the original authors thinking? > > >> > > >> And there was that comment about the file containing the data upon > > >> install. > > >> Which seemed wrong to me. > > >> > > >> They were probably thinking of the way 3.6 was packaged and > > >> distributed -- everyone built the system from source, upon building > > >> m3build/m3ship from C and m3 from assembly. > > >> > > >> That isn't a bad model, but we probably want both. > > >> > > >> There are at least three times the paths can be computed/recorded: > > >> 1) when you build libm3 > > >> 2) when you install libm3 > > >> #1 and #2 may or may not be close in time and have the same result. > > >> 3) by parsing cm3.cfg as needed > > >> > > >> #2 is more efficient than #3 and matches the old code, but #3 is how I > > >> left it, probably ok. > > >> > > >> - Jay > > >> > > > -- > > > Dragi?a Duri? > > > -- Dragi?a Duri? From hendrik at topoi.pooq.com Fri Jul 31 15:13:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 09:13:41 -0400 Subject: [M3devel] CM3 resource access at Elego, was: Re: Web page experimental colors In-Reply-To: References: <442486.20009.qm@web56806.mail.re3.yahoo.com> <20090730221642.ui4ezxwa8okcwcg0@mail.elegosoft.com> <20090731123115.GA17620@topoi.pooq.com> Message-ID: <20090731131340.GC17620@topoi.pooq.com> On Fri, Jul 31, 2009 at 12:36:26PM +0000, Jay K wrote: > > We should be a little careful with ARM_LINUX imho. And MIPS_LINUX. > > > Those target name might be ok, and they'd refer to Linux 2.6+ with glibc. > Many ARM and MIPS Linux systems aren't that. > > > ARM has old ABI and new ABI, at the kernel level. Nokia uses the new ABI, I believe. Maemo, its OS, is debian-derived, but it is *not* Debian. Though it is possible to set it up to use Debian user-space in a chroot on the maemo kernel. > It it also common to replace glibc with uclibc. > I don't know if they are binary compatible or not. > My Linux/arm machine/device is old ABI and uclibc. So it's probably not. > It seems that if you are building your own kernel, > it is trivial to use old ABI. It isn't like it is incompatible > with new hardware, I think. I think whoever put together > the Western Digital MyBook World Edition just took the default. > > > MIPS..well, I was surprised. I installed "Tomato" on my router. > It is /very/ low end, but it does have a builtin SMB client, therefore > it has infinite diskspace. > It uses Linux 2.4, and I think/assume uclibc. > > > MIPS also has big and little endian and I don't know if either is > more common or if it is an even split. I know the hardware has that option -- it's controlled by a bit in some processor register. I remember wonderein, years ago, whether the OS allowed one to set that on a per-process basis, or even more finely. The situation reminds me of the IBM 360, which had a similar bit to control whether its native instructino set would support decimal operations in ASCII or in EBCDIC. But because changing that bit was a privileged operation, no one really got to set it, and everything was always EBCDIC. With the 370, I believe IBM discontinued the ASCII option. No one had ever used it. -- hendrik From hosking at cs.purdue.edu Fri Jul 31 15:42:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 09:42:19 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: I don't care if future versions are not compilable with old cm3. But, vice versa, old versions should always be compilable with new cm3. My gut feelings run along the lines of what Randy has said. I do think that the average user should accept std as the install, while min is for power-users who know what they are doing. Does that jive with other people's expectations? On 31 Jul 2009, at 03:39, Jay K wrote: > > I'm sorry but I'm feeling very impatient... > > > > >> Namely, that "min" is the smallest distribution we plan to make >> available > > > Ok, that is clearer. > That is not scientific but a matter of a decision. > We could decide that min==std, not a bad decision really, since it > gives users fewer confusing choices, and provides one package per > platform, with no overlap. > On the downside, it isn't small and some people might say we look fat. > > > > >> My "opinion" is that "min" should contain only what is >> necessary for a working cm3 compiler > > > Now you have made a policy decision. An acceptable one. > But not necessarily how it should and not necessarily consistent > with some other things. > > >> Anything added to "min" that isn't necessary to accomplish >> building the remaining packages would be considered superfluous, >> in my opinion. > >> Some amount of superfluous on a given platform may be >> tolerable in order to reach consistency among all supported >> platforms regarding the composition of "min". Thus, >> if cm3cg is needed for "min" on some platforms, but not all, >> it is tolerable (IMO) to make it a standard component of "min" >> on all platforms. > > > cm3cg doesn't really make sense on NT386 though. > I've probably thrown it in somewhat by accident. > If it is there, it'll depend on Cygwin, and NT386 will just ignore > it completely, except for wasted diskspace, network traffic. > > >> WRT#4, although doc may not be needed to run cm3, it is needed >> for folks to reference and understand cm3. > > > Now you are expanding the definition. The documentation is all > online too. > I'm certainly fine with including the documentation. Just be clear > that "min"'s definition is expanding. > (I'm fine with not distributing min at all, as I said, min==std?) > > >> The naive user new to cm3 normally expects to get some documentation. > > I don't expect naive users to build cm3 themselves. > This is in fact a reason not to provide min at all, but std. > That way, the naive person who thinks he is expert won't make a > mistake. > Really. On the other hand, there are the masochists among us who use > the Debian "netinst" and chose no additional packages during setup. :) > If one has the time/patience, it can also be educational to create > arbitrary difficult situations and work your way out of them. Really. > (Why does anyone use Linux after all?) > > >> If the default is no documentation, how does the poor sap know >> how to get the documentation and install it? > > > Poor saps should use "std", not "min". Right? > What is "min"? The "minimum" distribution that is useful for > "everyone" or the minimal distribution to build cm3? > > > I should correct myself by the way. > cm3cg is not needed in "min". > It is "easily" just not quickly built from just cm3 and the m3-sys/ > m3cc part of the tree, and really cm3 is hardly needed for that (but > cm3 is definitely needed for building everything else, so needed > overall). > > >> [Jay] docs/examples I think it was >> The "typical" installation choice should install it by default. > > > "typical" or "min"? > > >> WRT#11, now we are finally getting to the meat of my questions. So, >> if I understand you correctly, you are saying that building the "min" >> group of packages does not recreate for me exactly what > > > You must start with a prebuilt compiler (cm3). > Whether you rebuild the compiler or not is somewhat a matter of taste. > Indeed it is more tasteful to build it. > In which case indeed, you need to build "front", but "front" need > not be in the distribution. "front" is in fact basically just cm3, > and I think cm3cg. > > > Again again again, the "package groups" are just a redundant > encoding of the dependency tree that is encoded in the m3makefiles. > We could the entire scripts directory and pretty much everything > would work about the same. It would just be a little tedious. > > > More and more I think we should actually delete a lot of this. > We should keep the PKGS file, or make cm3 able to figure it out, and > the "scripts" should just accept an end goal -- "cm3", and it should > read the m3makefiles and build the dependency graph from the buttom > up to the goal. > > > There could be special goal called "all", AND we could have the > broken m3makefiles all filter themselves out. > > Perhaps a special group called "test", whose membership is implied > by path? > > > But now, you see, the more of these features I add, the more I'm > back to reinventing these minor little scripts and package groups > that we have. > > > But do you see, that these aren't sort of all that significant? > What you need to build is whatever m3makefiles lists in imports, and > follow the transitive closure. And cm3cg is sort of different -- > because it isn't a linked/library dependency, but rather because the > config files tries to run a program (cm3cg) and that program needs > to therefore exist somewhere. That is, the linked/library > dependencies are encoded in a nice declarative way in the > m3makefiles but the dependency on cm3cg is encoded in an imperative > way. > > > > > My interpretion of "min" has been roughly a minimal distribution > that one can start with in order to build cm3, EVEN IF old cm3 > cannot build m3core and libm3 from current source. The part I don't > understand is that last point -- is it considered a recurring > problem? Where is the line? What about sysutils? Is sysutils > expected to be forever bound to be buildable by arbitrarily old > compilers? > > > Do we make a release shortly any such incompatibilities occur? > Do we in fact not cater to such incompatibilities, and "min" > therefore does NOT include m3core and libm3? > > > Historically there was actually a more recurring problem here, > around the list of targets. That is gone now. However there are > still occasional problems like LONGINT. It seems to me this is > somewhat of a problem of predicting the future, which is impossible. > But also taking out very cheap insurance against the only fairly > small number of bad futures. That is, throwing in m3core and libm3 > is cheap, and it allows for future versions to not be compilable > with old cm3, and that not being a big deal. > This is all a bit gray and heuristic however. > > > If today you start with a 5.4 or such cm3, indeed, you cannot build > m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3. > > > If you start with yesterday's cm3 however, you can build today's > entire system, without also having yesterday's m3core/libm3 (nor > cm3cg). > > > See? It depends. > And mitigating the worst case is perhaps worthwhile and cheap. > > > And it depends because the system is necessarily circular. > ("necessary" because the compiler is written in Modula-3) > Breaking circular dependencies requires cheating. > Changes in circular graphs can require cheating differently. > > > > If we do this, it is probably a good idea to also include sysutils > in min -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 31 15:42:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 09:42:33 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <767A3979-1061-449C-8B28-900EE49D2848@cs.purdue.edu> Correct. On 31 Jul 2009, at 03:59, Jay K wrote: > > [truncated right about here..] > > > If we do this, it is probably a good idea to also include sysutils > in min -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jul 31 16:05:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 16:05:46 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> Quoting Tony Hosking : > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Sorry, I only now caught up with _some_ of the mails on the m3devel list. Too much traffic for me to digest. I gather there's been a long discussion that `min' is not really useful as it is not enough to build the system. When we started the cm3 5 business many years ago with lots of uncompilable sources from Farshad Nayeri, we invented the following sets of packages: all - obvious meaning. most packages did not compile at all. std - the set of packages shipped as compilable and usable with every new release core - a useful but small set of packages including everything to bootstrap the compiler boot - the minimal set to bootstrap the compiler min - the minimal set useful for anyone (not wanting to compiler cm3) As of today, std = all, and boot isn't used any more as far as a I see. I'm fine with any changes in the pragmatics or intended use of these package sets though. Just wanted to throw in some history. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Jul 31 17:13:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:13:58 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> Message-ID: <20090731151357.GA18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > >I don't care if future versions are not compilable with old cm3. But, > >vice versa, old versions should always be compilable with new cm3. > > > >My gut feelings run along the lines of what Randy has said. I do > >think that the average user should accept std as the install, while > >min is for power-users who know what they are doing. Does that jive > >with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. Is that becaouse no one ever boots the compiler any more? Or because there are better ways to do it? -- hendrik > > I'm fine with any changes in the pragmatics or intended use of these > package sets though. Just wanted to throw in some history. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Fri Jul 31 17:19:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:19:15 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> Message-ID: <20090731151914.GB18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 09:42:19AM -0400, Tony Hosking wrote: > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Debian treats packages that share code as an anathema. So if there's a min package, they'd insist that std has the min parts removed from it, and depend on the min package instead of including it. Of course, the package description of the min package could gently advise potential users that they probably want to use the 'std' package instead... -- hendrik From hendrik at topoi.pooq.com Fri Jul 31 17:20:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:20:48 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731151357.GA18289@topoi.pooq.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> Message-ID: <20090731152047.GC18289@topoi.pooq.com> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > > >I don't care if future versions are not compilable with old cm3. But, > > >vice versa, old versions should always be compilable with new cm3. > > > > > >My gut feelings run along the lines of what Randy has said. I do > > >think that the average user should accept std as the install, while > > >min is for power-users who know what they are doing. Does that jive > > >with other people's expectations? > > > > Sorry, I only now caught up with _some_ of the mails on the m3devel > > list. Too much traffic for me to digest. > > > > I gather there's been a long discussion that `min' is not really > > useful as it is not enough to build the system. When we started > > the cm3 5 business many years ago with lots of uncompilable sources > > from Farshad Nayeri, we invented the following sets of packages: > > > > all - obvious meaning. most packages did not compile at all. > > std - the set of packages shipped as compilable and usable with > > every new release > > core - a useful but small set of packages including everything to > > bootstrap the compiler > > boot - the minimal set to bootstrap the compiler > > min - the minimal set useful for anyone (not wanting to compiler cm3) > > > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik I guess I should mention that ebian is perfectly happy if one source parckage (possibly the entire working cm3 system) generates multiple binary packages. -- hendrik From rcoleburn at scires.com Fri Jul 31 17:33:09 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 11:33:09 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content Message-ID: <4A72D418020000D70005DF1C@scires.com> Jay: The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. Regards, Randy Coleburn >>> Jay K 07/31/09 2:51 AM >>> BUILD_DIR is defined. cm3 requires it too. It just isn't necessarily defined in the toplevel file, but in a file that gets included. > PKG_USE I believe that is also defined but I'll check. > DOC_INSTALL I doubt that is defined because I never saw it used. I can add it back. > INSTALL_ROOT That is certainly defined, and very important. > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR These are probably also not defined because I never saw them used. I can add them back..but they are actually very user specific. I can add defaults like: BROWSER=iexplore.exe EDITOR=notepad.exe BROWSER=firefox-bin EDITOR=/usr/bin/vi I'll do a little reserach and try to find defaults that work. - Jay ________________________________ > Date: Fri, 31 Jul 2009 01:05:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content > > > > > > > > Jay et al: > > > > On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. > > > > cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". > > > > I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. > > > > At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. > > > > In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. > > > > In particular, these are: > > BUILD_DIR > > PKG_USE > > DOC_INSTALL > > INSTALL_ROOT > > INITIAL_CM3_IDE_BROWSER > > INITIAL_CM3_IDE_EDITOR > > > > If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. > > > > I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. > > > > It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. > > > > Regards, > > Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 17:27:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 15:27:57 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090731152047.GC18289@topoi.pooq.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> Message-ID: What does it mean to boot the compiler? I build the compiler from nothing but the compiler itself, and config files, and C compiler and linker, cvs to get all the source. That's not nothing, but it about the smallest start you can have, unless you rewrite the compiler in C, then you can start without the Modula-3 compiler. But at certain points in time this would not work, due to m3core and/or libm3 problems. It does work today. Is that booting? In future I'd like to dynamically link cm3, so I'd start with cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" dependencies. Many other systems do dynamically link to this extent and we can to. I'm not just being obnoxious. Really, what does it mean? Should we just ship std and that's it? And even drop the name from it? cm3-PPC_LINUX-5.8.2.tar.gz ? (No need to say "POSIX", it is redundant). Just one download per platform? Not a big matrix of packages to test? Or do we look too fat in that packaging? :) Will too much stuff confuse users? Or mitigate the bulk with a little documentation/tutorial? Something like this: There are many libraries and packages. You do not need to worry about them. Here is hello world for a command line program: ... And for a gui program: ... And a minimal sample interoperating with C: ... And a minimal sample using Modula-3's RPC called "network objects": ... CM3 4.1 had some like this that were nice, presumably we have them. - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>> Quoting Tony Hosking : >>> >>>>I don't care if future versions are not compilable with old cm3. But, >>>>vice versa, old versions should always be compilable with new cm3. >>>> >>>>My gut feelings run along the lines of what Randy has said. I do >>>>think that the average user should accept std as the install, while >>>>min is for power-users who know what they are doing. Does that jive >>>>with other people's expectations? >>> >>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>> list. Too much traffic for me to digest. >>> >>> I gather there's been a long discussion that `min' is not really >>> useful as it is not enough to build the system. When we started >>> the cm3 5 business many years ago with lots of uncompilable sources >>> from Farshad Nayeri, we invented the following sets of packages: >>> >>> all - obvious meaning. most packages did not compile at all. >>> std - the set of packages shipped as compilable and usable with >>> every new release >>> core - a useful but small set of packages including everything to >>> bootstrap the compiler >>> boot - the minimal set to bootstrap the compiler >>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>> >>> As of today, std = all, and boot isn't used any more as far as a I see. >> >> Is that becaouse no one ever boots the compiler any more? Or because >> there are better ways to do it? >> >> -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > From jay.krell at cornell.edu Fri Jul 31 17:31:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 15:31:14 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content In-Reply-To: <4A72D418020000D70005DF1C@scires.com> References: <4A72D418020000D70005DF1C@scires.com> Message-ID: MxConfig.Get() is able to retrieve the included part. MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. It is exactly the same code as the compiler uses. The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. Due to missing variables MxConfig would kind of give up and return NULL. I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. Maybe we should work this into the .msi?? - Jay ________________________________ > Date: Fri, 31 Jul 2009 11:33:09 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. > > > > I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. > > > > Regards, > > Randy Coleburn > >>>> Jay K 07/31/09 2:51 AM>>> > > BUILD_DIR is defined. > cm3 requires it too. > It just isn't necessarily defined in the toplevel file, but in a file that gets included. > >> PKG_USE > > > I believe that is also defined but I'll check. > > >> DOC_INSTALL > > I doubt that is defined because I never saw it used. I can add it back. > > >> INSTALL_ROOT > > > That is certainly defined, and very important. > > >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR > > > These are probably also not defined because I never saw them used. > I can add them back..but they are actually very user specific. > I can add defaults like: > > BROWSER=iexplore.exe > EDITOR=notepad.exe > > BROWSER=firefox-bin > EDITOR=/usr/bin/vi > > > I'll do a little reserach and try to find defaults that work. > > > - Jay > > ________________________________ >> Date: Fri, 31 Jul 2009 01:05:45 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >> >> >> >> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >> >> >> >> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >> >> >> >> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >> >> >> >> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >> >> >> >> In particular, these are: >> >> BUILD_DIR >> >> PKG_USE >> >> DOC_INSTALL >> >> INSTALL_ROOT >> >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR >> >> >> >> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >> >> >> >> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >> >> >> >> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >> >> >> >> Regards, >> >> Randy Coleburn From hendrik at topoi.pooq.com Fri Jul 31 17:51:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 11:51:05 -0400 Subject: [M3devel] Platform names Message-ID: <20090731155105.GA18363@topoi.pooq.com> Just to make life complicated, Debian has announced that the next release (squeeze, once it's stable) will have multiarch support (which means we'll be able to run 32-bit and 64-bit programs on AMD64), and that it will support both the Linux and BSD kernels. So Debian won't necessarily be a Linux system any more. -- hendrik From rcoleburn at scires.com Fri Jul 31 18:01:24 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 12:01:24 -0400 Subject: [M3devel] package groups question Message-ID: <4A72DD14020000D70005DF68@scires.com> Olaf: Thanks for the brief history lesson. These definitions coincide with my recollection. >From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". My problem has been a misunderstanding of "min", having thought that I could use min to bootstrap the compiler. My bad here. Jay has been talking about tracing graphs and figuring out everything from m3makefiles. In a distributed development environment, I'm not sure this approach works well. I am fine with continued use of PkgInfo.txt. I've been able to generate scripts using it with relative ease. For this release, I think we have at least 2 groups of "users" to be supported: 1. The power users who know enough to tweak the details of their installation, rebuild the compiler, etc. etc. They want the flexibility to tailor everything. You, Jay, Tony, etc. are in this camp. 2. The average or even new user who just wants a simple install that works out-of-the-box. He doesn't want anything complicated to install. He probably won't rebuild the compiler and is content to update his system whenever a new release is made. Obviously, folks from camp #2 may promote themselves to camp #1 after sufficient experience. If we agree on these two camps, I think that your definition of "min" is ok, but I would argue that "std" should include the documentation, examples, and pre-built binaries and sources for all packages known to work on all platforms. That would allow "std" to satisfy camp #2. Thus, "std" should be the recommended option for most users. The power users in camp #1 can start with either "min" or "std" and they have the knowledge to transform either of these into "all" or whatever sub-grouping they want. I appreciate everything Jay is doing, but I think he is so deep in the details right now, and also still looking forward past this release, that his responses to my questions aren't really answering what I'm trying to discuss regarding nailing down this release. Sure, with complete knowledge you can do most anything, but I'm looking at what I can do using cm3ide and the cm3.exe builder/compiler and the "min" and "std" releases using the default install locations. I'm heading south for a family reunion. I'll try to check email some this weekend, but it will be sparse. As soon as I can, I'll try to put some of what I've gleaned in a text file we can add to the documentation/web. Regards, Randy Coileburn >>> Olaf Wagner 07/31/09 10:08 AM >>> Quoting Tony Hosking : > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? Sorry, I only now caught up with _some_ of the mails on the m3devel list. Too much traffic for me to digest. I gather there's been a long discussion that `min' is not really useful as it is not enough to build the system. When we started the cm3 5 business many years ago with lots of uncompilable sources from Farshad Nayeri, we invented the following sets of packages: all - obvious meaning. most packages did not compile at all. std - the set of packages shipped as compilable and usable with every new release core - a useful but small set of packages including everything to bootstrap the compiler boot - the minimal set to bootstrap the compiler min - the minimal set useful for anyone (not wanting to compiler cm3) As of today, std = all, and boot isn't used any more as far as a I see. I'm fine with any changes in the pragmatics or intended use of these package sets though. Just wanted to throw in some history. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jul 31 18:09:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 31 Jul 2009 12:09:57 -0400 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content Message-ID: <4A72DF15020000D70005DF87@scires.com> Jay: The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly. I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.) Let me know if you have any ideas on why Vista is different in this regard. Regards, Randy >>> Jay K 07/31/09 11:33 AM >>> MxConfig.Get() is able to retrieve the included part. MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. It is exactly the same code as the compiler uses. The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. Due to missing variables MxConfig would kind of give up and return NULL. I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. Maybe we should work this into the .msi?? - Jay ________________________________ > Date: Fri, 31 Jul 2009 11:33:09 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. > > > > I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. > > > > Regards, > > Randy Coleburn > >>>> Jay K 07/31/09 2:51 AM>>> > > BUILD_DIR is defined. > cm3 requires it too. > It just isn't necessarily defined in the toplevel file, but in a file that gets included. > >> PKG_USE > > > I believe that is also defined but I'll check. > > >> DOC_INSTALL > > I doubt that is defined because I never saw it used. I can add it back. > > >> INSTALL_ROOT > > > That is certainly defined, and very important. > > >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR > > > These are probably also not defined because I never saw them used. > I can add them back..but they are actually very user specific. > I can add defaults like: > > BROWSER=iexplore.exe > EDITOR=notepad.exe > > BROWSER=firefox-bin > EDITOR=/usr/bin/vi > > > I'll do a little reserach and try to find defaults that work. > > > - Jay > > ________________________________ >> Date: Fri, 31 Jul 2009 01:05:45 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >> >> >> >> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >> >> >> >> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >> >> >> >> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >> >> >> >> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >> >> >> >> In particular, these are: >> >> BUILD_DIR >> >> PKG_USE >> >> DOC_INSTALL >> >> INSTALL_ROOT >> >> INITIAL_CM3_IDE_BROWSER >> >> INITIAL_CM3_IDE_EDITOR >> >> >> >> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >> >> >> >> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >> >> >> >> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >> >> >> >> Regards, >> >> Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:21:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:21:22 +0000 Subject: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content In-Reply-To: <4A72DF15020000D70005DF87@scires.com> References: <4A72DF15020000D70005DF87@scires.com> Message-ID: Randy, when you test start /wait on Vista (or XP for that matter), make sure first that there are no instances of iexplore.exe in taskmgr. I bet what is happening is that the new iexplore.exe you ran actually did exit. Each user should probably have his own web server? Or, what is wrong with keeping the web server running even after the browser exits? I will double check BUILD_DIR, but the code is shared with cm3. How about the other variables? Vista vs. XP should not matter here. - Jay ________________________________ > Date: Fri, 31 Jul 2009 12:09:57 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content > > > > Jay: > > > > The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly. > > > > I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.) > > > > Let me know if you have any ideas on why Vista is different in this regard. > > > > Regards, > > Randy > >>>> Jay K 07/31/09 11:33 AM>>> > > MxConfig.Get() is able to retrieve the included part. > MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it. > It is exactly the same code as the compiler uses. > The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day. > Due to missing variables MxConfig would kind of give up and return NULL. > > > I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value. > > > Maybe we should work this into the .msi?? > > > - Jay > > > ________________________________ >> Date: Fri, 31 Jul 2009 11:33:09 -0400 >> From: rcoleburn at scires.com >> To: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content >> >> >> >> Jay: >> >> >> >> The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file. >> >> >> >> I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes. >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay K 07/31/09 2:51 AM>>> >> >> BUILD_DIR is defined. >> cm3 requires it too. >> It just isn't necessarily defined in the toplevel file, but in a file that gets included. >> >>> PKG_USE >> >> >> I believe that is also defined but I'll check. >> >> >>> DOC_INSTALL >> >> I doubt that is defined because I never saw it used. I can add it back. >> >> >>> INSTALL_ROOT >> >> >> That is certainly defined, and very important. >> >> >>> INITIAL_CM3_IDE_BROWSER >>> >>> INITIAL_CM3_IDE_EDITOR >> >> >> These are probably also not defined because I never saw them used. >> I can add them back..but they are actually very user specific. >> I can add defaults like: >> >> BROWSER=iexplore.exe >> EDITOR=notepad.exe >> >> BROWSER=firefox-bin >> EDITOR=/usr/bin/vi >> >> >> I'll do a little reserach and try to find defaults that work. >> >> >> - Jay >> >> ________________________________ >>> Date: Fri, 31 Jul 2009 01:05:45 -0400 >>> From: rcoleburn at scires.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content >>> >>> >>> >>> >>> >>> >>> >>> Jay et al: >>> >>> >>> >>> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg. >>> >>> >>> >>> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386". >>> >>> >>> >>> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation. >>> >>> >>> >>> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach. >>> >>> >>> >>> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg. >>> >>> >>> >>> In particular, these are: >>> >>> BUILD_DIR >>> >>> PKG_USE >>> >>> DOC_INSTALL >>> >>> INSTALL_ROOT >>> >>> INITIAL_CM3_IDE_BROWSER >>> >>> INITIAL_CM3_IDE_EDITOR >>> >>> >>> >>> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away. >>> >>> >>> >>> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable. >>> >>> >>> >>> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure. >>> >>> >>> >>> Regards, >>> >>> Randy Coleburn From wagner at elegosoft.com Fri Jul 31 18:27:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 18:27:47 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> Message-ID: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> I meant getting the first instance of cm3 5.1 run on a certain platform. And there was of course a first platform. We used the SRC compiler, the cm3 4.1 from Critical Mass, and the PM3 compiler on different platforms. Later we used cross-compilation almost exclusively. I assume that cross-compilation support has improved dramatically with all your changes. Olaf Quoting Jay K : > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- >> Date: Fri, 31 Jul 2009 11:20:48 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>> Quoting Tony Hosking : >>>> >>>>> I don't care if future versions are not compilable with old cm3. But, >>>>> vice versa, old versions should always be compilable with new cm3. >>>>> >>>>> My gut feelings run along the lines of what Randy has said. I do >>>>> think that the average user should accept std as the install, while >>>>> min is for power-users who know what they are doing. Does that jive >>>>> with other people's expectations? >>>> >>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>> list. Too much traffic for me to digest. >>>> >>>> I gather there's been a long discussion that `min' is not really >>>> useful as it is not enough to build the system. When we started >>>> the cm3 5 business many years ago with lots of uncompilable sources >>>> from Farshad Nayeri, we invented the following sets of packages: >>>> >>>> all - obvious meaning. most packages did not compile at all. >>>> std - the set of packages shipped as compilable and usable with >>>> every new release >>>> core - a useful but small set of packages including everything to >>>> bootstrap the compiler >>>> boot - the minimal set to bootstrap the compiler >>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>> >>>> As of today, std = all, and boot isn't used any more as far as a I see. >>> >>> Is that becaouse no one ever boots the compiler any more? Or because >>> there are better ways to do it? >>> >>> -- hendrik >> >> I guess I should mention that ebian is perfectly happy if one source >> parckage (possibly the entire working cm3 system) generates multiple >> binary packages. >> >> -- hendrik >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jul 31 18:31:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 12:31:49 -0400 Subject: [M3devel] package groups question In-Reply-To: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add? On 31 Jul 2009, at 12:27, Olaf Wagner wrote: > I meant getting the first instance of cm3 5.1 run on a certain > platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >> dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >>> wrote: >>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>> Quoting Tony Hosking : >>>>> >>>>>> I don't care if future versions are not compilable with old >>>>>> cm3. But, >>>>>> vice versa, old versions should always be compilable with new >>>>>> cm3. >>>>>> >>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>> think that the average user should accept std as the install, >>>>>> while >>>>>> min is for power-users who know what they are doing. Does that >>>>>> jive >>>>>> with other people's expectations? >>>>> >>>>> Sorry, I only now caught up with _some_ of the mails on the >>>>> m3devel >>>>> list. Too much traffic for me to digest. >>>>> >>>>> I gather there's been a long discussion that `min' is not really >>>>> useful as it is not enough to build the system. When we started >>>>> the cm3 5 business many years ago with lots of uncompilable >>>>> sources >>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>> >>>>> all - obvious meaning. most packages did not compile at all. >>>>> std - the set of packages shipped as compilable and usable with >>>>> every new release >>>>> core - a useful but small set of packages including everything to >>>>> bootstrap the compiler >>>>> boot - the minimal set to bootstrap the compiler >>>>> min - the minimal set useful for anyone (not wanting to compiler >>>>> cm3) >>>>> >>>>> As of today, std = all, and boot isn't used any more as far as a >>>>> I see. >>>> >>>> Is that becaouse no one ever boots the compiler any more? Or >>>> because >>>> there are better ways to do it? >>>> >>>> -- hendrik >>> >>> I guess I should mention that ebian is perfectly happy if one source >>> parckage (possibly the entire working cm3 system) generates multiple >>> binary packages. >>> >>> -- hendrik >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:35:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:35:19 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: I actually think cross compilation support might have been very good in the first place. :) In either case, yes, cross compilation support is good and easy now, if it wasn't earlier. I only ever cross compile cm3 itself though, not the entire system. Mainly what I did is some automation in pylib.py, which isn't all it should be, but again, enough for cm3. It's arguably not much more than your scripts. Oh, well, I also changed cm3.cfg to probe around for a reasonable cm3cg, so I could stop constantly overwriting the One /cm3/bin/cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. Really we should ship to /cm3/bin/host/target/cm3cg probably. Cross compiling the entire system will be useful for distribution purposes, but not in this release probably. It will enable us to claim to build a distribution for some target, without actually having the target available..which is a little bit dishonest, granted, you couldn't have run the tests. However it also allows cross building the entire system for slow targets, that you do have and will run the tests on, e.g. iphone, mips network router, my SGI machine, etc. If you booted from other distributions...these package groups refer to something in them?? - Jay ---------------------------------------- > Date: Fri, 31 Jul 2009 18:27:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>> Quoting Tony Hosking : >>>>> >>>>>> I don't care if future versions are not compilable with old cm3. But, >>>>>> vice versa, old versions should always be compilable with new cm3. >>>>>> >>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>> think that the average user should accept std as the install, while >>>>>> min is for power-users who know what they are doing. Does that jive >>>>>> with other people's expectations? >>>>> >>>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>>> list. Too much traffic for me to digest. >>>>> >>>>> I gather there's been a long discussion that `min' is not really >>>>> useful as it is not enough to build the system. When we started >>>>> the cm3 5 business many years ago with lots of uncompilable sources >>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>> >>>>> all - obvious meaning. most packages did not compile at all. >>>>> std - the set of packages shipped as compilable and usable with >>>>> every new release >>>>> core - a useful but small set of packages including everything to >>>>> bootstrap the compiler >>>>> boot - the minimal set to bootstrap the compiler >>>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>>> >>>>> As of today, std = all, and boot isn't used any more as far as a I see. >>>> >>>> Is that becaouse no one ever boots the compiler any more? Or because >>>> there are better ways to do it? >>>> >>>> -- hendrik >>> >>> I guess I should mention that ebian is perfectly happy if one source >>> parckage (possibly the entire working cm3 system) generates multiple >>> binary packages. >>> >>> -- hendrik >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 31 18:43:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:43:04 +0000 Subject: [M3devel] package groups question In-Reply-To: <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> Message-ID: That reminds me, darn it.. Yes I think the INTEGER/FLOAT things are ok now. I had hit problems in float and/or double bootstrapping where host and target differed in endian and fixed it. There were also 32bit/64bit problems there maybe, also now believed fixed. And gcc used to be partly to blame for problems here, but has been fixed. I even suggested they rev the documented caveats about building for Alpha and I think they did. I do bootstrap from host-generated .s files. I understand you could bootstrap from .mc files instead. Maybe even textual ones? That you use as a distribution format? Advantages/disadvantages? Minor one is that you'd have to build m3cc without the small aid of cm3..not a big deal, just configure -disable-bootstrap -disable-multilibs && make and ignore all my little tweaks in the m3makefile. If not textual, mc files are less readable..but assembly is unreadable to most people anyway.. There are bugs here though. - I left in the hack you didn't like in order to bootstrap from 32bit to 64bit, where TEXTs are limited to 4gig, rather than some much larger value on 64bit systems. The front end should be doing target math there not host math. - You can't bootstrap from 64bit to 32bit due to some similar small bug in the front end. Probably also a target math vs. host math thing. We already have the code to simulate target math, we just have to use it a little more. (This is what gcc now uses gmp/mpfr for presumably, like wrt constant propagation.) - Jay ________________________________ > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Fri, 31 Jul 2009 12:31:49 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add? > > On 31 Jul 2009, at 12:27, Olaf Wagner wrote: > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K>: > > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hosking at cs.purdue.edu Fri Jul 31 18:46:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 12:46:26 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: Agreed, cross-compilation only needed for cm3 itself. PM3 used to distribute the derived .s files for each platform and installation required building cm3 from those. That way there was no need to deliver an executable cm3. It was all source. On 31 Jul 2009, at 12:35, Jay K wrote: > > I actually think cross compilation support might have been very good > in the first place. :) > In either case, yes, cross compilation support is good and easy now, > if it wasn't earlier. > I only ever cross compile cm3 itself though, not the entire system. > Mainly what I did is some automation in pylib.py, which isn't all it > should be, but again, enough for cm3. > It's arguably not much more than your scripts. > > > Oh, well, I also changed cm3.cfg to probe around for a reasonable > cm3cg, so I could stop constantly overwriting the One /cm3/bin/ > cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. > Really we should ship to /cm3/bin/host/target/cm3cg probably. > > > Cross compiling the entire system will be useful for distribution > purposes, but not in this release probably. > It will enable us to claim to build a distribution for some target, > without actually having the target available..which is a little bit > dishonest, granted, you couldn't have run the tests. > > > However it also allows cross building the entire system for slow > targets, that you do have and will run the tests on, e.g. iphone, > mips network router, my SGI machine, etc. > > > If you booted from other distributions...these package groups refer > to something in them?? > > > - Jay > > ---------------------------------------- >> Date: Fri, 31 Jul 2009 18:27:47 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> I meant getting the first instance of cm3 5.1 run on a certain >> platform. >> And there was of course a first platform. We used the SRC compiler, >> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >> platforms. Later we used cross-compilation almost exclusively. >> >> I assume that cross-compilation support has improved dramatically >> with all your changes. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> What does it mean to boot the compiler? >>> >>> >>> I build the compiler from nothing but the compiler itself, >>> and config files, and C compiler and linker, cvs >>> to get all the source. >>> That's not nothing, but it about the smallest start you can have, >>> unless you rewrite the compiler in C, then you can start without >>> the Modula-3 compiler. But at certain points in time this >>> would not work, due to m3core and/or libm3 problems. >>> It does work today. >>> >>> >>> Is that booting? >>> >>> >>> In future I'd like to dynamically link cm3, so I'd start with >>> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >>> dynamic" >>> dependencies. Many other systems do dynamically link to this extent >>> and we can to. >>> >>> >>> I'm not just being obnoxious. >>> Really, what does it mean? >>> >>> >>> Should we just ship std and that's it? >>> And even drop the name from it? >>> cm3-PPC_LINUX-5.8.2.tar.gz ? >>> >>> >>> (No need to say "POSIX", it is redundant). >>> Just one download per platform? >>> Not a big matrix of packages to test? >>> >>> >>> Or do we look too fat in that packaging? :) >>> >>> >>> Will too much stuff confuse users? >>> >>> >>> Or mitigate the bulk with a little documentation/tutorial? >>> >>> >>> Something like this: >>> >>> There are many libraries and packages. >>> You do not need to worry about them. >>> Here is hello world for a command line program: >>> ... >>> And for a gui program: >>> ... >>> And a minimal sample interoperating with C: >>> ... >>> And a minimal sample using Modula-3's RPC called "network objects": >>> ... >>> >>> CM3 4.1 had some like this that were nice, presumably we have them. >>> >>> - Jay >>> >>> >>> >>> >>> ---------------------------------------- >>>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>>> From: hendrik at topoi.pooq.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] package groups question >>>> >>>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >>>> wrote: >>>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>>> Quoting Tony Hosking : >>>>>> >>>>>>> I don't care if future versions are not compilable with old >>>>>>> cm3. But, >>>>>>> vice versa, old versions should always be compilable with new >>>>>>> cm3. >>>>>>> >>>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>>> think that the average user should accept std as the install, >>>>>>> while >>>>>>> min is for power-users who know what they are doing. Does that >>>>>>> jive >>>>>>> with other people's expectations? >>>>>> >>>>>> Sorry, I only now caught up with _some_ of the mails on the >>>>>> m3devel >>>>>> list. Too much traffic for me to digest. >>>>>> >>>>>> I gather there's been a long discussion that `min' is not really >>>>>> useful as it is not enough to build the system. When we started >>>>>> the cm3 5 business many years ago with lots of uncompilable >>>>>> sources >>>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>>> >>>>>> all - obvious meaning. most packages did not compile at all. >>>>>> std - the set of packages shipped as compilable and usable with >>>>>> every new release >>>>>> core - a useful but small set of packages including everything to >>>>>> bootstrap the compiler >>>>>> boot - the minimal set to bootstrap the compiler >>>>>> min - the minimal set useful for anyone (not wanting to >>>>>> compiler cm3) >>>>>> >>>>>> As of today, std = all, and boot isn't used any more as far as >>>>>> a I see. >>>>> >>>>> Is that becaouse no one ever boots the compiler any more? Or >>>>> because >>>>> there are better ways to do it? >>>>> >>>>> -- hendrik >>>> >>>> I guess I should mention that ebian is perfectly happy if one >>>> source >>>> parckage (possibly the entire working cm3 system) generates >>>> multiple >>>> binary packages. >>>> >>>> -- hendrik >>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 31 18:49:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:49:41 +0000 Subject: [M3devel] "how to build a distribution" Message-ID: On this matter there's actually more stuff worth mentioning. Like, you always need various packages/libraries/tools that are often not in default minimal OS installs. ODBC, X Windows, Postgres, bc, flex, bison, gcc, make, cvs, opengl, etc. None of those are in the default Debian netinst for example. And esp. the first few are not in many systems' default installations. You don't need any of these, except for gcc basically, to use Modula-3. But if you want to include all of "std", you need the C headers and/or librarie (often just libraries). I never was able to find opengl for I386_DARWIN (not MacOSX). - Jay From jay.krell at cornell.edu Fri Jul 31 18:53:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Jul 2009 16:53:05 +0000 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: I like that PM3/SRC model, just haven't (re)implemented it yet. In that model I believe we'd have binary and source distributions. binary for the less patient. Source for the less trusting. Albeit assembly source. something like that. The source distribution is also more portable, like to multiple versions of the OS, since the library names haven't been locked in yet -- Olaf and I found that OpenBSD is kind of a pain there, they rev the name of libc.so and apparently break old binaries. Maybe there is a compat option we didn't see (didn't look). We'll see about changes/progress here in future releases. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 31 Jul 2009 12:46:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > Agreed, cross-compilation only needed for cm3 itself. PM3 used to distribute the derived .s files for each platform and installation required building cm3 from those. That way there was no need to deliver an executable cm3. It was all source. > > On 31 Jul 2009, at 12:35, Jay K wrote: > > > I actually think cross compilation support might have been very good in the first place. :) > In either case, yes, cross compilation support is good and easy now, if it wasn't earlier. > I only ever cross compile cm3 itself though, not the entire system. > Mainly what I did is some automation in pylib.py, which isn't all it should be, but again, enough for cm3. > It's arguably not much more than your scripts. > > > Oh, well, I also changed cm3.cfg to probe around for a reasonable cm3cg, so I could stop constantly overwriting the One /cm3/bin/cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. > Really we should ship to /cm3/bin/host/target/cm3cg probably. > > > Cross compiling the entire system will be useful for distribution purposes, but not in this release probably. > It will enable us to claim to build a distribution for some target, without actually having the target available..which is a little bit dishonest, granted, you couldn't have run the tests. > > > However it also allows cross building the entire system for slow targets, that you do have and will run the tests on, e.g. iphone, mips network router, my SGI machine, etc. > > > If you booted from other distributions...these package groups refer to something in them?? > > > - Jay > > ---------------------------------------- > Date: Fri, 31 Jul 2009 18:27:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > I meant getting the first instance of cm3 5.1 run on a certain platform. > And there was of course a first platform. We used the SRC compiler, > the cm3 4.1 from Critical Mass, and the PM3 compiler on different > platforms. Later we used cross-compilation almost exclusively. > > I assume that cross-compilation support has improved dramatically > with all your changes. > > Olaf > > Quoting Jay K : > > > What does it mean to boot the compiler? > > > I build the compiler from nothing but the compiler itself, > and config files, and C compiler and linker, cvs > to get all the source. > That's not nothing, but it about the smallest start you can have, > unless you rewrite the compiler in C, then you can start without > the Modula-3 compiler. But at certain points in time this > would not work, due to m3core and/or libm3 problems. > It does work today. > > > Is that booting? > > > In future I'd like to dynamically link cm3, so I'd start with > cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" > dependencies. Many other systems do dynamically link to this extent > and we can to. > > > I'm not just being obnoxious. > Really, what does it mean? > > > Should we just ship std and that's it? > And even drop the name from it? > cm3-PPC_LINUX-5.8.2.tar.gz ? > > > (No need to say "POSIX", it is redundant). > Just one download per platform? > Not a big matrix of packages to test? > > > Or do we look too fat in that packaging? :) > > > Will too much stuff confuse users? > > > Or mitigate the bulk with a little documentation/tutorial? > > > Something like this: > > There are many libraries and packages. > You do not need to worry about them. > Here is hello world for a command line program: > ... > And for a gui program: > ... > And a minimal sample interoperating with C: > ... > And a minimal sample using Modula-3's RPC called "network objects": > ... > > CM3 4.1 had some like this that were nice, presumably we have them. > > - Jay > > > > > ---------------------------------------- > Date: Fri, 31 Jul 2009 11:20:48 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > I don't care if future versions are not compilable with old cm3. But, > vice versa, old versions should always be compilable with new cm3. > > My gut feelings run along the lines of what Randy has said. I do > think that the average user should accept std as the install, while > min is for power-users who know what they are doing. Does that jive > with other people's expectations? > > Sorry, I only now caught up with _some_ of the mails on the m3devel > list. Too much traffic for me to digest. > > I gather there's been a long discussion that `min' is not really > useful as it is not enough to build the system. When we started > the cm3 5 business many years ago with lots of uncompilable sources > from Farshad Nayeri, we invented the following sets of packages: > > all - obvious meaning. most packages did not compile at all. > std - the set of packages shipped as compilable and usable with > every new release > core - a useful but small set of packages including everything to > bootstrap the compiler > boot - the minimal set to bootstrap the compiler > min - the minimal set useful for anyone (not wanting to compiler cm3) > > As of today, std = all, and boot isn't used any more as far as a I see. > > Is that becaouse no one ever boots the compiler any more? Or because > there are better ways to do it? > > -- hendrik > > I guess I should mention that ebian is perfectly happy if one source > parckage (possibly the entire working cm3 system) generates multiple > binary packages. > > -- hendrik > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hendrik at topoi.pooq.com Fri Jul 31 19:40:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 31 Jul 2009 13:40:49 -0400 Subject: [M3devel] "how to build a distribution" In-Reply-To: References: Message-ID: <20090731174049.GA18464@topoi.pooq.com> On Fri, Jul 31, 2009 at 04:49:41PM +0000, Jay K wrote: > > On this matter there's actually more stuff worth mentioning. > > > Like, you always need various packages/libraries/tools that are often not in default minimal OS installs. > > > ODBC, X Windows, Postgres, bc, flex, bison, gcc, make, cvs, opengl, etc. > > > None of those are in the default Debian netinst for example. > And esp. the first few are not in many systems' default installations. >From the Debian binary point of view, the packages providing these should should be dependencies of the various libraries we generate that use them. Installing our library would then cause the other tools to be installed automatically. > > You don't need any of these, except for gcc basically, to use Modula-3. > But if you want to include all of "std", you need the C headers and/or librarie (often just libraries). Actually, Debian distinguishes several kind of packages: source packages -- the actual source code that people edit. binary packages -- what you need to use the software Usually executables and/or shared libraries doc -- often recommended or suggested by the binary packages and dev packages dev packages -- what you need to develop other software that uses the binary package. For C, this often consists of header files and kind of shim libraries that serve no purpose except to load the shared libraries. In our case, the source package for cm3 will probably have a build-dependency on one of the binary packages it generates. I wonder how C handles this. And how does this map onto the files Modula 3 uses and builds? -- hendrik From wagner at elegosoft.com Fri Jul 31 23:29:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 31 Jul 2009 23:29:29 +0200 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> Message-ID: <20090731232929.r2v9z92sggkoogsc@mail.elegosoft.com> Quoting Tony Hosking : > Agreed, cross-compilation only needed for cm3 itself. PM3 used to > distribute the derived .s files for each platform and installation > required building cm3 from those. That way there was no need to > deliver an executable cm3. It was all source. I would like that to be possible with cm3, too. But we never built up the infrastructure to do it. Not for this release though ;-) Let's try to ge something delivered. Olaf > On 31 Jul 2009, at 12:35, Jay K wrote: > >> >> I actually think cross compilation support might have been very >> good in the first place. :) >> In either case, yes, cross compilation support is good and easy >> now, if it wasn't earlier. >> I only ever cross compile cm3 itself though, not the entire system. >> Mainly what I did is some automation in pylib.py, which isn't all >> it should be, but again, enough for cm3. >> It's arguably not much more than your scripts. >> >> >> Oh, well, I also changed cm3.cfg to probe around for a reasonable >> cm3cg, so I could stop constantly overwriting the One /cm3/bin/ >> cm3cg, but just use CVSROOT/m3-sys/m3cc/host-target/cm3cg. >> Really we should ship to /cm3/bin/host/target/cm3cg probably. >> >> >> Cross compiling the entire system will be useful for distribution >> purposes, but not in this release probably. >> It will enable us to claim to build a distribution for some target, >> without actually having the target available..which is a little >> bit dishonest, granted, you couldn't have run the tests. >> >> >> However it also allows cross building the entire system for slow >> targets, that you do have and will run the tests on, e.g. iphone, >> mips network router, my SGI machine, etc. >> >> >> If you booted from other distributions...these package groups refer >> to something in them?? >> >> >> - Jay >> >> ---------------------------------------- >>> Date: Fri, 31 Jul 2009 18:27:47 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] package groups question >>> >>> I meant getting the first instance of cm3 5.1 run on a certain platform. >>> And there was of course a first platform. We used the SRC compiler, >>> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >>> platforms. Later we used cross-compilation almost exclusively. >>> >>> I assume that cross-compilation support has improved dramatically >>> with all your changes. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> What does it mean to boot the compiler? >>>> >>>> >>>> I build the compiler from nothing but the compiler itself, >>>> and config files, and C compiler and linker, cvs >>>> to get all the source. >>>> That's not nothing, but it about the smallest start you can have, >>>> unless you rewrite the compiler in C, then you can start without >>>> the Modula-3 compiler. But at certain points in time this >>>> would not work, due to m3core and/or libm3 problems. >>>> It does work today. >>>> >>>> >>>> Is that booting? >>>> >>>> >>>> In future I'd like to dynamically link cm3, so I'd start with >>>> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic" >>>> dependencies. Many other systems do dynamically link to this extent >>>> and we can to. >>>> >>>> >>>> I'm not just being obnoxious. >>>> Really, what does it mean? >>>> >>>> >>>> Should we just ship std and that's it? >>>> And even drop the name from it? >>>> cm3-PPC_LINUX-5.8.2.tar.gz ? >>>> >>>> >>>> (No need to say "POSIX", it is redundant). >>>> Just one download per platform? >>>> Not a big matrix of packages to test? >>>> >>>> >>>> Or do we look too fat in that packaging? :) >>>> >>>> >>>> Will too much stuff confuse users? >>>> >>>> >>>> Or mitigate the bulk with a little documentation/tutorial? >>>> >>>> >>>> Something like this: >>>> >>>> There are many libraries and packages. >>>> You do not need to worry about them. >>>> Here is hello world for a command line program: >>>> ... >>>> And for a gui program: >>>> ... >>>> And a minimal sample interoperating with C: >>>> ... >>>> And a minimal sample using Modula-3's RPC called "network objects": >>>> ... >>>> >>>> CM3 4.1 had some like this that were nice, presumably we have them. >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Fri, 31 Jul 2009 11:20:48 -0400 >>>>> From: hendrik at topoi.pooq.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] package groups question >>>>> >>>>> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote: >>>>>> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >>>>>>> Quoting Tony Hosking : >>>>>>> >>>>>>>> I don't care if future versions are not compilable with old cm3. But, >>>>>>>> vice versa, old versions should always be compilable with new cm3. >>>>>>>> >>>>>>>> My gut feelings run along the lines of what Randy has said. I do >>>>>>>> think that the average user should accept std as the install, while >>>>>>>> min is for power-users who know what they are doing. Does that jive >>>>>>>> with other people's expectations? >>>>>>> >>>>>>> Sorry, I only now caught up with _some_ of the mails on the m3devel >>>>>>> list. Too much traffic for me to digest. >>>>>>> >>>>>>> I gather there's been a long discussion that `min' is not really >>>>>>> useful as it is not enough to build the system. When we started >>>>>>> the cm3 5 business many years ago with lots of uncompilable sources >>>>>>> from Farshad Nayeri, we invented the following sets of packages: >>>>>>> >>>>>>> all - obvious meaning. most packages did not compile at all. >>>>>>> std - the set of packages shipped as compilable and usable with >>>>>>> every new release >>>>>>> core - a useful but small set of packages including everything to >>>>>>> bootstrap the compiler >>>>>>> boot - the minimal set to bootstrap the compiler >>>>>>> min - the minimal set useful for anyone (not wanting to compiler cm3) >>>>>>> >>>>>>> As of today, std = all, and boot isn't used any more as far as >>>>>>> a I see. >>>>>> >>>>>> Is that becaouse no one ever boots the compiler any more? Or because >>>>>> there are better ways to do it? >>>>>> >>>>>> -- hendrik >>>>> >>>>> I guess I should mention that ebian is perfectly happy if one source >>>>> parckage (possibly the entire working cm3 system) generates multiple >>>>> binary packages. >>>>> >>>>> -- hendrik >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194