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